From volker.simonis at gmail.com Mon Jan 4 19:26:34 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 4 Jan 2016 20:26:34 +0100 Subject: RFR(XS): 8146425: After change 8142907 'EXCLUDE_FILE' is wrongly interpreted as pattern Message-ID: Hi, could someone please review the following small fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8146425/ https://bugs.openjdk.java.net/browse/JDK-8146425 Change "8142907: Integration of minor fixes from the build-infra project" has introduced a new parameter called EXCLUDE_PATTERN for calls to SetupNativeCompilation. Unfortunately this change also altered the semantics of EXCLUDE_FILE which is now interpreted as a pattern of the form "*EXCLUDE_FILE". This is because of the following code: ifneq ($$($1_ALL_EXCLUDE_FILES),) $1_EXCLUDE_FILES_PAT := $$($1_ALL_EXCLUDE_FILES) \ $$(foreach i,$$($1_SRC),$$(addprefix $$i/,$$($1_ALL_EXCLUDE_FILES))) $1_EXCLUDE_FILES_PAT := $$(addprefix %,$$($1_EXCLUDE_FILES_PAT)) $1_SRCS := $$(filter-out $$($1_EXCLUDE_FILES_PAT),$$($1_SRCS)) $1_EXCLUDE_FILES_PAT is initialized to contain all the simple file names which are to be excluded plus all of these file names prefixed with each src path. In the next step, all the entries in $1_EXCLUDE_FILES_PAT are converted to patterns by prefixing them with the wildcard character "%". Finally, the patterns are matched against all the existing source files. This leads to the problem that every file which was given as EXCLUDE_FILES will be converted into a "%EXCLUDE_FILES" pattern thus effectively excluding not just files with the name EXCLUDE_FILES but actually all files ending in EXCLUDE_FILES. This hit us badly on AIX where we have the implementation file AixNativeThread.c and the exclude NativeThread.c. After change 8142907 AixNativeThread.c was silently excluded from the compilation leading to errors during runtime because the file contained some native methods from sun.nio.ch which are not always used. Thank you and best regards, Volker From kim.barrett at oracle.com Tue Jan 5 02:25:28 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 4 Jan 2016 21:25:28 -0500 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> Message-ID: <98B07F13-1D90-4DEC-AAED-D791F4666BF7@oracle.com> On Dec 18, 2015, at 7:41 PM, Kim Barrett wrote: > > On Dec 16, 2015, at 8:50 AM, Magnus Ihse Bursie wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 >> >> /Magnus > > I only looked at hotspot files. > > [?] > There are a couple of "TBD"s below that I need to spend more time on. > Back from holiday, and here?s my comments on those two TBDs ------------------------------------------------------------------------------ hotspot/agent/src/share/native/sadis.c 96 return (int)strlen(buf); The only call to the (file-scoped) getLastErrorString function is Java_sun_jvm_hotspot_asm_Disassembler_load_1library, which ignores the result. It would be better to change the return type of getLastErrorString to void and update the return statements accordingly. ------------------------------------------------------------------------------ hotspot/src/share/vm/adlc/arena.hpp 74 // Usual (non-placement) deallocation function to allow placement delete use size_t 75 // See 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 2. 76 void operator delete(void* p); and associated code in the .cpp file. I think this is another C++11 change: http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#429 I think the proposed code change is OK, although the comment is problematic: [basic.stc.dynamic.deallocation] is C++03 3.7.3.2 and C++11 3.7.4.2. Also, the standard change that leads to this code change is in C++11 5.3.4 [expr.new] paragraph 20 (C++02 p 19). Also, I *think* with the addition of the one-arg operator delete we don't actually use the two-arg form. If so, then I suggest removing it and the proposed new comment for the one-arg form. ------------------------------------------------------------------------------ From erik.joelsson at oracle.com Tue Jan 5 08:51:19 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Jan 2016 09:51:19 +0100 Subject: RFR(XS): 8146425: After change 8142907 'EXCLUDE_FILE' is wrongly interpreted as pattern In-Reply-To: References: Message-ID: <568B8407.4020501@oracle.com> Hello Volker, I believe this change in behavior was intended at the time. In an internal situation where the same thing hit us, we changed the exclude pattern in question by adding a slash at the front: '/NativeThread.c'. I should also inform you that I'm currently working on a major overhaul of all the INCLUDE/EXCLUDE file finding mechanisms in the build so that SetupNativeCompilation, SetupJavaCompilation, SetupCopyFiles etc all use the same semantics (and same implementation) for finding source files. I'm doing the work in the sandbox forest in a branch named erikj-makefilesets-branch if you are interested in checking it out. So far I've converted SetupCopyFiles and SetupTextFileProcessing. The common source file definitions can be found in the new FileSet.gmk: http://hg.openjdk.java.net/jdk9/sandbox/file/7ad550ee1d67/make/common/FileSet.gmk /Erik On 2016-01-04 20:26, Volker Simonis wrote: > Hi, > > could someone please review the following small fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8146425/ > https://bugs.openjdk.java.net/browse/JDK-8146425 > > Change "8142907: Integration of minor fixes from the build-infra > project" has introduced a new parameter called EXCLUDE_PATTERN for > calls to SetupNativeCompilation. > > Unfortunately this change also altered the semantics of EXCLUDE_FILE > which is now interpreted as a pattern of the form "*EXCLUDE_FILE". > This is because of the following code: > > ifneq ($$($1_ALL_EXCLUDE_FILES),) > $1_EXCLUDE_FILES_PAT := $$($1_ALL_EXCLUDE_FILES) \ > $$(foreach i,$$($1_SRC),$$(addprefix $$i/,$$($1_ALL_EXCLUDE_FILES))) > $1_EXCLUDE_FILES_PAT := $$(addprefix %,$$($1_EXCLUDE_FILES_PAT)) > $1_SRCS := $$(filter-out $$($1_EXCLUDE_FILES_PAT),$$($1_SRCS)) > > $1_EXCLUDE_FILES_PAT is initialized to contain all the simple file > names which are to be excluded plus all of these file names prefixed > with each src path. In the next step, all the entries in > $1_EXCLUDE_FILES_PAT are converted to patterns by prefixing them with > the wildcard character "%". Finally, the patterns are matched against > all the existing source files. This leads to the problem that every > file which was given as EXCLUDE_FILES will be converted into a > "%EXCLUDE_FILES" pattern thus effectively excluding not just files > with the name EXCLUDE_FILES but actually all files ending in > EXCLUDE_FILES. > > This hit us badly on AIX where we have the implementation file > AixNativeThread.c and the exclude NativeThread.c. After change 8142907 > AixNativeThread.c was silently excluded from the compilation leading > to errors during runtime because the file contained some native > methods from sun.nio.ch which are not always used. > > Thank you and best regards, > Volker From erik.joelsson at oracle.com Tue Jan 5 08:53:57 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Jan 2016 09:53:57 +0100 Subject: RFR(XS): 8146425: After change 8142907 'EXCLUDE_FILE' is wrongly interpreted as pattern In-Reply-To: <568B8407.4020501@oracle.com> References: <568B8407.4020501@oracle.com> Message-ID: <568B84A5.4020608@oracle.com> On 2016-01-05 09:51, Erik Joelsson wrote: > Hello Volker, > > I believe this change in behavior was intended at the time. In an > internal situation where the same thing hit us, we changed the exclude > pattern in question by adding a slash at the front: '/NativeThread.c'. > And the reason we needed this change was that we wanted to exclude files by name without having to specify sub directory. Typically in Hotspot, there are a lot of sub directories with native source. /Erik > I should also inform you that I'm currently working on a major > overhaul of all the INCLUDE/EXCLUDE file finding mechanisms in the > build so that SetupNativeCompilation, SetupJavaCompilation, > SetupCopyFiles etc all use the same semantics (and same > implementation) for finding source files. I'm doing the work in the > sandbox forest in a branch named erikj-makefilesets-branch if you are > interested in checking it out. So far I've converted SetupCopyFiles > and SetupTextFileProcessing. The common source file definitions can be > found in the new FileSet.gmk: > > http://hg.openjdk.java.net/jdk9/sandbox/file/7ad550ee1d67/make/common/FileSet.gmk > > > /Erik > > On 2016-01-04 20:26, Volker Simonis wrote: >> Hi, >> >> could someone please review the following small fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8146425/ >> https://bugs.openjdk.java.net/browse/JDK-8146425 >> >> Change "8142907: Integration of minor fixes from the build-infra >> project" has introduced a new parameter called EXCLUDE_PATTERN for >> calls to SetupNativeCompilation. >> >> Unfortunately this change also altered the semantics of EXCLUDE_FILE >> which is now interpreted as a pattern of the form "*EXCLUDE_FILE". >> This is because of the following code: >> >> ifneq ($$($1_ALL_EXCLUDE_FILES),) >> $1_EXCLUDE_FILES_PAT := $$($1_ALL_EXCLUDE_FILES) \ >> $$(foreach i,$$($1_SRC),$$(addprefix >> $$i/,$$($1_ALL_EXCLUDE_FILES))) >> $1_EXCLUDE_FILES_PAT := $$(addprefix %,$$($1_EXCLUDE_FILES_PAT)) >> $1_SRCS := $$(filter-out $$($1_EXCLUDE_FILES_PAT),$$($1_SRCS)) >> >> $1_EXCLUDE_FILES_PAT is initialized to contain all the simple file >> names which are to be excluded plus all of these file names prefixed >> with each src path. In the next step, all the entries in >> $1_EXCLUDE_FILES_PAT are converted to patterns by prefixing them with >> the wildcard character "%". Finally, the patterns are matched against >> all the existing source files. This leads to the problem that every >> file which was given as EXCLUDE_FILES will be converted into a >> "%EXCLUDE_FILES" pattern thus effectively excluding not just files >> with the name EXCLUDE_FILES but actually all files ending in >> EXCLUDE_FILES. >> >> This hit us badly on AIX where we have the implementation file >> AixNativeThread.c and the exclude NativeThread.c. After change 8142907 >> AixNativeThread.c was silently excluded from the compilation leading >> to errors during runtime because the file contained some native >> methods from sun.nio.ch which are not always used. >> >> Thank you and best regards, >> Volker > From erik.joelsson at oracle.com Tue Jan 5 10:58:25 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Jan 2016 11:58:25 +0100 Subject: RFR: JDK-8146403: Windows build can be faster Message-ID: <568BA1D1.2060104@oracle.com> Hello, During the hotspot makefile conversion, we have been reminded of inefficiencies when running make in Cygwin. We still have a pretty severe performance regression in the new hotspot build compared to the old on Windows in certain situations, my laptop being one such situation. A recent comparison there between just the old and new hotspot build: release new 00:04:30 release old 00:03:10 fastdebug new 00:04:59 fastdebug old 00:03:37 Much of the extra time is spent spawning various shell processes for book keeping, like saving failure logs, creating header dependency files etc. It also takes a very long time to do a "do nothing" rebuild when nothing has changed. On my laptop, repeating "make jimages" often takes as long as 40 seconds to figure out that nothing needs to be rebuilt. In this case there are several culprits. I have been working on improvements in these areas to reduce the overhead. The "do nothing" rebuild of jimages is down to around 25 seconds. A full images build is around 1-2 minutes faster from 24 to 22 minutes, but fluctuates quite a bit. The new hotspot build is also improved: release: 3:44 fastdebug: 4:02 Here is a list of the kinds of changes I've made: * Rewrote logger.sh to use a different construct. It drastically reduces the number of bash processes being spawned. Basically you can pipe like this: "> >(tee logfile) 2> >(tee logfile >&2)". I also managed to reduce the extra sed/grep commands needed for the header dependencies even more. A side effect of this is that the log files for each native compilation unit are always saved instead of being deleted on successful compilation. I see no issue with this. * Changed all recipes that contain echo for logging to instead use new LogInfo macro, which in turn calls $(info ) if appropriate. * Changed all recipes that contain mkdir to instead use MakeDir macro, which only executes mkdir if the directory doesn't exist. * In HotspotWrapper.gmk there is an optimization to avoid calling the hotspot makefiles at all if nothing has changed. This runs a find over the whole hotspot repository. I reduced this to only run over src and make sub dirs to avoid the pretty large test dir (since test/closed has grown quite a bit). * Split Tools.gmk into CompileTools.gmk and Tools.gmk, to avoid having the buildtools compilation being reevaluated by all makefiles needing the tools definitions. * Split Modules.gmk to avoid having the module deps generation being reevaluated multiple times. Made the new GenerateModuleDeps.gmk an explicit call from Init.gmk. Since these improvements affect much more than just the new hotspot build, I intend to push this to JDK 9 directly. Bug: https://bugs.openjdk.java.net/browse/JDK-8146403 Webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.01/ /Erik From markus.gronlund at oracle.com Tue Jan 5 11:09:45 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 5 Jan 2016 03:09:45 -0800 (PST) Subject: RFR: JDK-8146403: Windows build can be faster In-Reply-To: <568BA1D1.2060104@oracle.com> References: <568BA1D1.2060104@oracle.com> Message-ID: <145741b2-4933-462b-947a-6261dd58437e@default> (not a review) Thanks a bunch Erik for taking this on, +1. The Cygwin abstraction layer is just painfully slow - as you point out, it has to do with spawning new process all the time (where the Windows architecture expects fat processes using many threads instead of short lived Posix processes/threads). Just the amounts of spawned /usr/bin/find.exe in directories containing a lot of files is proportionally slow to the many files contained therein (could be an optimization hint to split files into several directories perhaps). Any work here to help speed this up is very much appreciated. Thanks again Markus -----Original Message----- From: Erik Joelsson Sent: den 5 januari 2016 11:58 To: build-dev Subject: RFR: JDK-8146403: Windows build can be faster Hello, During the hotspot makefile conversion, we have been reminded of inefficiencies when running make in Cygwin. We still have a pretty severe performance regression in the new hotspot build compared to the old on Windows in certain situations, my laptop being one such situation. A recent comparison there between just the old and new hotspot build: release new 00:04:30 release old 00:03:10 fastdebug new 00:04:59 fastdebug old 00:03:37 Much of the extra time is spent spawning various shell processes for book keeping, like saving failure logs, creating header dependency files etc. It also takes a very long time to do a "do nothing" rebuild when nothing has changed. On my laptop, repeating "make jimages" often takes as long as 40 seconds to figure out that nothing needs to be rebuilt. In this case there are several culprits. I have been working on improvements in these areas to reduce the overhead. The "do nothing" rebuild of jimages is down to around 25 seconds. A full images build is around 1-2 minutes faster from 24 to 22 minutes, but fluctuates quite a bit. The new hotspot build is also improved: release: 3:44 fastdebug: 4:02 Here is a list of the kinds of changes I've made: * Rewrote logger.sh to use a different construct. It drastically reduces the number of bash processes being spawned. Basically you can pipe like this: "> >(tee logfile) 2> >(tee logfile >&2)". I also managed to reduce the extra sed/grep commands needed for the header dependencies even more. A side effect of this is that the log files for each native compilation unit are always saved instead of being deleted on successful compilation. I see no issue with this. * Changed all recipes that contain echo for logging to instead use new LogInfo macro, which in turn calls $(info ) if appropriate. * Changed all recipes that contain mkdir to instead use MakeDir macro, which only executes mkdir if the directory doesn't exist. * In HotspotWrapper.gmk there is an optimization to avoid calling the hotspot makefiles at all if nothing has changed. This runs a find over the whole hotspot repository. I reduced this to only run over src and make sub dirs to avoid the pretty large test dir (since test/closed has grown quite a bit). * Split Tools.gmk into CompileTools.gmk and Tools.gmk, to avoid having the buildtools compilation being reevaluated by all makefiles needing the tools definitions. * Split Modules.gmk to avoid having the module deps generation being reevaluated multiple times. Made the new GenerateModuleDeps.gmk an explicit call from Init.gmk. Since these improvements affect much more than just the new hotspot build, I intend to push this to JDK 9 directly. Bug: https://bugs.openjdk.java.net/browse/JDK-8146403 Webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.01/ /Erik From volker.simonis at gmail.com Tue Jan 5 13:27:03 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 5 Jan 2016 14:27:03 +0100 Subject: RFR(XS): 8146425: After change 8142907 'EXCLUDE_FILE' is wrongly interpreted as pattern In-Reply-To: <568B84A5.4020608@oracle.com> References: <568B8407.4020501@oracle.com> <568B84A5.4020608@oracle.com> Message-ID: I see, but as far as I understand all you are saying only applies to the new hotspot-build system in build-infra. So I really don't see why these changes had to be integrated into jdk9-dev. As far as I can see, EXCLUDE_PATTERNS isn't currently used anywhere in jdk9-dev. And I'm a little reluctant to use '/NativeThread.c' as you proposed because according to the link you posted this pattern will be interpreted as an absolute path with the upcoming changes you are doing. What is the actual problem with my fix? I could build without problems. And I still think EXCLUDE_FILE should just be just a file name. If you need to exclude a file by name without specifying a sub-directory you can build such a functionality into the new EXCLUDE_PATTERNS. I really would appreciate a fast resolution of this problem because all our AIX builds are currently unusable. Thank you and best regards, Volker On Tue, Jan 5, 2016 at 9:53 AM, Erik Joelsson wrote: > > > On 2016-01-05 09:51, Erik Joelsson wrote: >> >> Hello Volker, >> >> I believe this change in behavior was intended at the time. In an internal >> situation where the same thing hit us, we changed the exclude pattern in >> question by adding a slash at the front: '/NativeThread.c'. >> > And the reason we needed this change was that we wanted to exclude files by > name without having to specify sub directory. Typically in Hotspot, there > are a lot of sub directories with native source. > > /Erik > >> I should also inform you that I'm currently working on a major overhaul of >> all the INCLUDE/EXCLUDE file finding mechanisms in the build so that >> SetupNativeCompilation, SetupJavaCompilation, SetupCopyFiles etc all use the >> same semantics (and same implementation) for finding source files. I'm doing >> the work in the sandbox forest in a branch named erikj-makefilesets-branch >> if you are interested in checking it out. So far I've converted >> SetupCopyFiles and SetupTextFileProcessing. The common source file >> definitions can be found in the new FileSet.gmk: >> >> >> http://hg.openjdk.java.net/jdk9/sandbox/file/7ad550ee1d67/make/common/FileSet.gmk >> >> /Erik >> >> On 2016-01-04 20:26, Volker Simonis wrote: >>> >>> Hi, >>> >>> could someone please review the following small fix: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8146425/ >>> https://bugs.openjdk.java.net/browse/JDK-8146425 >>> >>> Change "8142907: Integration of minor fixes from the build-infra >>> project" has introduced a new parameter called EXCLUDE_PATTERN for >>> calls to SetupNativeCompilation. >>> >>> Unfortunately this change also altered the semantics of EXCLUDE_FILE >>> which is now interpreted as a pattern of the form "*EXCLUDE_FILE". >>> This is because of the following code: >>> >>> ifneq ($$($1_ALL_EXCLUDE_FILES),) >>> $1_EXCLUDE_FILES_PAT := $$($1_ALL_EXCLUDE_FILES) \ >>> $$(foreach i,$$($1_SRC),$$(addprefix >>> $$i/,$$($1_ALL_EXCLUDE_FILES))) >>> $1_EXCLUDE_FILES_PAT := $$(addprefix %,$$($1_EXCLUDE_FILES_PAT)) >>> $1_SRCS := $$(filter-out $$($1_EXCLUDE_FILES_PAT),$$($1_SRCS)) >>> >>> $1_EXCLUDE_FILES_PAT is initialized to contain all the simple file >>> names which are to be excluded plus all of these file names prefixed >>> with each src path. In the next step, all the entries in >>> $1_EXCLUDE_FILES_PAT are converted to patterns by prefixing them with >>> the wildcard character "%". Finally, the patterns are matched against >>> all the existing source files. This leads to the problem that every >>> file which was given as EXCLUDE_FILES will be converted into a >>> "%EXCLUDE_FILES" pattern thus effectively excluding not just files >>> with the name EXCLUDE_FILES but actually all files ending in >>> EXCLUDE_FILES. >>> >>> This hit us badly on AIX where we have the implementation file >>> AixNativeThread.c and the exclude NativeThread.c. After change 8142907 >>> AixNativeThread.c was silently excluded from the compilation leading >>> to errors during runtime because the file contained some native >>> methods from sun.nio.ch which are not always used. >>> >>> Thank you and best regards, >>> Volker >> >> > From erik.joelsson at oracle.com Tue Jan 5 16:47:34 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Jan 2016 17:47:34 +0100 Subject: RFR(XS): 8146425: After change 8142907 'EXCLUDE_FILE' is wrongly interpreted as pattern In-Reply-To: References: <568B8407.4020501@oracle.com> <568B84A5.4020608@oracle.com> Message-ID: <568BF3A6.8060201@oracle.com> Hello Volker, On 2016-01-05 14:27, Volker Simonis wrote: > I see, but as far as I understand all you are saying only applies to > the new hotspot-build system in build-infra. So I really don't see why > these changes had to be integrated into jdk9-dev. As far as I can see, > EXCLUDE_PATTERNS isn't currently used anywhere in jdk9-dev. That is correct. We use the functionality in build-infra/jdk9 for the new hotspot build. We integrated a bunch of general build changes early to reduce the burden of maintaining those changes in the build-infra repository. This was one of them. Some were relevant to jdk9, this one wasn't yet. > And I'm a little reluctant to use '/NativeThread.c' as you proposed > because according to the link you posted this pattern will be > interpreted as an absolute path with the upcoming changes you are > doing. In my changes, I have to change and verify all the includes/excludes everywhere since I'm changing the semantics again. I would promise to keep an extra eye on NativeThread.c. > What is the actual problem with my fix? I could build without > problems. And I still think EXCLUDE_FILE should just be just a file > name. If you need to exclude a file by name without specifying a > sub-directory you can build such a functionality into the new > EXCLUDE_PATTERNS. The problem is that we now have closed code where we already prepended a slash as part of the change. If you change this behavior back, I will need to quickly fix those closed places too. That is of course Oracle's problem and not OpenJDK's. While I agree that a parameter named "EXCLUDE_FILES" should probably just refer to exact filenames, I find the new semantics more useful, so the error is rather in the parameter name. Also note that SetupJavaCompilation has been working this way all along so this change was also intended to align the semantics between the different macros. > I really would appreciate a fast resolution of this problem because > all our AIX builds are currently unusable. I certainly understand that. /Erik > Thank you and best regards, > Volker > > > On Tue, Jan 5, 2016 at 9:53 AM, Erik Joelsson wrote: >> >> On 2016-01-05 09:51, Erik Joelsson wrote: >>> Hello Volker, >>> >>> I believe this change in behavior was intended at the time. In an internal >>> situation where the same thing hit us, we changed the exclude pattern in >>> question by adding a slash at the front: '/NativeThread.c'. >>> >> And the reason we needed this change was that we wanted to exclude files by >> name without having to specify sub directory. Typically in Hotspot, there >> are a lot of sub directories with native source. >> >> /Erik >> >>> I should also inform you that I'm currently working on a major overhaul of >>> all the INCLUDE/EXCLUDE file finding mechanisms in the build so that >>> SetupNativeCompilation, SetupJavaCompilation, SetupCopyFiles etc all use the >>> same semantics (and same implementation) for finding source files. I'm doing >>> the work in the sandbox forest in a branch named erikj-makefilesets-branch >>> if you are interested in checking it out. So far I've converted >>> SetupCopyFiles and SetupTextFileProcessing. The common source file >>> definitions can be found in the new FileSet.gmk: >>> >>> >>> http://hg.openjdk.java.net/jdk9/sandbox/file/7ad550ee1d67/make/common/FileSet.gmk >>> >>> /Erik >>> >>> On 2016-01-04 20:26, Volker Simonis wrote: >>>> Hi, >>>> >>>> could someone please review the following small fix: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8146425/ >>>> https://bugs.openjdk.java.net/browse/JDK-8146425 >>>> >>>> Change "8142907: Integration of minor fixes from the build-infra >>>> project" has introduced a new parameter called EXCLUDE_PATTERN for >>>> calls to SetupNativeCompilation. >>>> >>>> Unfortunately this change also altered the semantics of EXCLUDE_FILE >>>> which is now interpreted as a pattern of the form "*EXCLUDE_FILE". >>>> This is because of the following code: >>>> >>>> ifneq ($$($1_ALL_EXCLUDE_FILES),) >>>> $1_EXCLUDE_FILES_PAT := $$($1_ALL_EXCLUDE_FILES) \ >>>> $$(foreach i,$$($1_SRC),$$(addprefix >>>> $$i/,$$($1_ALL_EXCLUDE_FILES))) >>>> $1_EXCLUDE_FILES_PAT := $$(addprefix %,$$($1_EXCLUDE_FILES_PAT)) >>>> $1_SRCS := $$(filter-out $$($1_EXCLUDE_FILES_PAT),$$($1_SRCS)) >>>> >>>> $1_EXCLUDE_FILES_PAT is initialized to contain all the simple file >>>> names which are to be excluded plus all of these file names prefixed >>>> with each src path. In the next step, all the entries in >>>> $1_EXCLUDE_FILES_PAT are converted to patterns by prefixing them with >>>> the wildcard character "%". Finally, the patterns are matched against >>>> all the existing source files. This leads to the problem that every >>>> file which was given as EXCLUDE_FILES will be converted into a >>>> "%EXCLUDE_FILES" pattern thus effectively excluding not just files >>>> with the name EXCLUDE_FILES but actually all files ending in >>>> EXCLUDE_FILES. >>>> >>>> This hit us badly on AIX where we have the implementation file >>>> AixNativeThread.c and the exclude NativeThread.c. After change 8142907 >>>> AixNativeThread.c was silently excluded from the compilation leading >>>> to errors during runtime because the file contained some native >>>> methods from sun.nio.ch which are not always used. >>>> >>>> Thank you and best regards, >>>> Volker >>> From volker.simonis at gmail.com Tue Jan 5 17:42:06 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 5 Jan 2016 18:42:06 +0100 Subject: RFR(XS): 8146425: After change 8142907 'EXCLUDE_FILE' is wrongly interpreted as pattern In-Reply-To: <568BF3A6.8060201@oracle.com> References: <568B8407.4020501@oracle.com> <568B84A5.4020608@oracle.com> <568BF3A6.8060201@oracle.com> Message-ID: OK, I only want to get this fixed now. Do you agree with the new fix which is AIX-only and prepends '/' to the filename as suggested by you: http://cr.openjdk.java.net/~simonis/webrevs/2016/8146425.v1/ Regards, Volker On Tue, Jan 5, 2016 at 5:47 PM, Erik Joelsson wrote: > Hello Volker, > > On 2016-01-05 14:27, Volker Simonis wrote: >> >> I see, but as far as I understand all you are saying only applies to >> the new hotspot-build system in build-infra. So I really don't see why >> these changes had to be integrated into jdk9-dev. As far as I can see, >> EXCLUDE_PATTERNS isn't currently used anywhere in jdk9-dev. > > That is correct. We use the functionality in build-infra/jdk9 for the new > hotspot build. We integrated a bunch of general build changes early to > reduce the burden of maintaining those changes in the build-infra > repository. This was one of them. Some were relevant to jdk9, this one > wasn't yet. >> >> And I'm a little reluctant to use '/NativeThread.c' as you proposed >> because according to the link you posted this pattern will be >> interpreted as an absolute path with the upcoming changes you are >> doing. > > In my changes, I have to change and verify all the includes/excludes > everywhere since I'm changing the semantics again. I would promise to keep > an extra eye on NativeThread.c. >> >> What is the actual problem with my fix? I could build without >> problems. And I still think EXCLUDE_FILE should just be just a file >> name. If you need to exclude a file by name without specifying a >> sub-directory you can build such a functionality into the new >> EXCLUDE_PATTERNS. > > The problem is that we now have closed code where we already prepended a > slash as part of the change. If you change this behavior back, I will need > to quickly fix those closed places too. That is of course Oracle's problem > and not OpenJDK's. > > While I agree that a parameter named "EXCLUDE_FILES" should probably just > refer to exact filenames, I find the new semantics more useful, so the error > is rather in the parameter name. Also note that SetupJavaCompilation has > been working this way all along so this change was also intended to align > the semantics between the different macros. >> >> I really would appreciate a fast resolution of this problem because >> all our AIX builds are currently unusable. > > I certainly understand that. > > /Erik > >> Thank you and best regards, >> Volker >> >> >> On Tue, Jan 5, 2016 at 9:53 AM, Erik Joelsson >> wrote: >>> >>> >>> On 2016-01-05 09:51, Erik Joelsson wrote: >>>> >>>> Hello Volker, >>>> >>>> I believe this change in behavior was intended at the time. In an >>>> internal >>>> situation where the same thing hit us, we changed the exclude pattern in >>>> question by adding a slash at the front: '/NativeThread.c'. >>>> >>> And the reason we needed this change was that we wanted to exclude files >>> by >>> name without having to specify sub directory. Typically in Hotspot, there >>> are a lot of sub directories with native source. >>> >>> /Erik >>> >>>> I should also inform you that I'm currently working on a major overhaul >>>> of >>>> all the INCLUDE/EXCLUDE file finding mechanisms in the build so that >>>> SetupNativeCompilation, SetupJavaCompilation, SetupCopyFiles etc all use >>>> the >>>> same semantics (and same implementation) for finding source files. I'm >>>> doing >>>> the work in the sandbox forest in a branch named >>>> erikj-makefilesets-branch >>>> if you are interested in checking it out. So far I've converted >>>> SetupCopyFiles and SetupTextFileProcessing. The common source file >>>> definitions can be found in the new FileSet.gmk: >>>> >>>> >>>> >>>> http://hg.openjdk.java.net/jdk9/sandbox/file/7ad550ee1d67/make/common/FileSet.gmk >>>> >>>> /Erik >>>> >>>> On 2016-01-04 20:26, Volker Simonis wrote: >>>>> >>>>> Hi, >>>>> >>>>> could someone please review the following small fix: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8146425/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8146425 >>>>> >>>>> Change "8142907: Integration of minor fixes from the build-infra >>>>> project" has introduced a new parameter called EXCLUDE_PATTERN for >>>>> calls to SetupNativeCompilation. >>>>> >>>>> Unfortunately this change also altered the semantics of EXCLUDE_FILE >>>>> which is now interpreted as a pattern of the form "*EXCLUDE_FILE". >>>>> This is because of the following code: >>>>> >>>>> ifneq ($$($1_ALL_EXCLUDE_FILES),) >>>>> $1_EXCLUDE_FILES_PAT := $$($1_ALL_EXCLUDE_FILES) \ >>>>> $$(foreach i,$$($1_SRC),$$(addprefix >>>>> $$i/,$$($1_ALL_EXCLUDE_FILES))) >>>>> $1_EXCLUDE_FILES_PAT := $$(addprefix %,$$($1_EXCLUDE_FILES_PAT)) >>>>> $1_SRCS := $$(filter-out $$($1_EXCLUDE_FILES_PAT),$$($1_SRCS)) >>>>> >>>>> $1_EXCLUDE_FILES_PAT is initialized to contain all the simple file >>>>> names which are to be excluded plus all of these file names prefixed >>>>> with each src path. In the next step, all the entries in >>>>> $1_EXCLUDE_FILES_PAT are converted to patterns by prefixing them with >>>>> the wildcard character "%". Finally, the patterns are matched against >>>>> all the existing source files. This leads to the problem that every >>>>> file which was given as EXCLUDE_FILES will be converted into a >>>>> "%EXCLUDE_FILES" pattern thus effectively excluding not just files >>>>> with the name EXCLUDE_FILES but actually all files ending in >>>>> EXCLUDE_FILES. >>>>> >>>>> This hit us badly on AIX where we have the implementation file >>>>> AixNativeThread.c and the exclude NativeThread.c. After change 8142907 >>>>> AixNativeThread.c was silently excluded from the compilation leading >>>>> to errors during runtime because the file contained some native >>>>> methods from sun.nio.ch which are not always used. >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>> >>>> > From erik.joelsson at oracle.com Tue Jan 5 17:49:34 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Jan 2016 18:49:34 +0100 Subject: RFR(XS): 8146425: After change 8142907 'EXCLUDE_FILE' is wrongly interpreted as pattern In-Reply-To: References: <568B8407.4020501@oracle.com> <568B84A5.4020608@oracle.com> <568BF3A6.8060201@oracle.com> Message-ID: <568C022E.60708@oracle.com> Looks good to me. Thank you Volker! I will make sure I don't break this with the upcoming changes. /Erik On 2016-01-05 18:42, Volker Simonis wrote: > OK, I only want to get this fixed now. > > Do you agree with the new fix which is AIX-only and prepends '/' to > the filename as suggested by you: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8146425.v1/ > > Regards, > Volker > > On Tue, Jan 5, 2016 at 5:47 PM, Erik Joelsson wrote: >> Hello Volker, >> >> On 2016-01-05 14:27, Volker Simonis wrote: >>> I see, but as far as I understand all you are saying only applies to >>> the new hotspot-build system in build-infra. So I really don't see why >>> these changes had to be integrated into jdk9-dev. As far as I can see, >>> EXCLUDE_PATTERNS isn't currently used anywhere in jdk9-dev. >> That is correct. We use the functionality in build-infra/jdk9 for the new >> hotspot build. We integrated a bunch of general build changes early to >> reduce the burden of maintaining those changes in the build-infra >> repository. This was one of them. Some were relevant to jdk9, this one >> wasn't yet. >>> And I'm a little reluctant to use '/NativeThread.c' as you proposed >>> because according to the link you posted this pattern will be >>> interpreted as an absolute path with the upcoming changes you are >>> doing. >> In my changes, I have to change and verify all the includes/excludes >> everywhere since I'm changing the semantics again. I would promise to keep >> an extra eye on NativeThread.c. >>> What is the actual problem with my fix? I could build without >>> problems. And I still think EXCLUDE_FILE should just be just a file >>> name. If you need to exclude a file by name without specifying a >>> sub-directory you can build such a functionality into the new >>> EXCLUDE_PATTERNS. >> The problem is that we now have closed code where we already prepended a >> slash as part of the change. If you change this behavior back, I will need >> to quickly fix those closed places too. That is of course Oracle's problem >> and not OpenJDK's. >> >> While I agree that a parameter named "EXCLUDE_FILES" should probably just >> refer to exact filenames, I find the new semantics more useful, so the error >> is rather in the parameter name. Also note that SetupJavaCompilation has >> been working this way all along so this change was also intended to align >> the semantics between the different macros. >>> I really would appreciate a fast resolution of this problem because >>> all our AIX builds are currently unusable. >> I certainly understand that. >> >> /Erik >> >>> Thank you and best regards, >>> Volker >>> >>> >>> On Tue, Jan 5, 2016 at 9:53 AM, Erik Joelsson >>> wrote: >>>> >>>> On 2016-01-05 09:51, Erik Joelsson wrote: >>>>> Hello Volker, >>>>> >>>>> I believe this change in behavior was intended at the time. In an >>>>> internal >>>>> situation where the same thing hit us, we changed the exclude pattern in >>>>> question by adding a slash at the front: '/NativeThread.c'. >>>>> >>>> And the reason we needed this change was that we wanted to exclude files >>>> by >>>> name without having to specify sub directory. Typically in Hotspot, there >>>> are a lot of sub directories with native source. >>>> >>>> /Erik >>>> >>>>> I should also inform you that I'm currently working on a major overhaul >>>>> of >>>>> all the INCLUDE/EXCLUDE file finding mechanisms in the build so that >>>>> SetupNativeCompilation, SetupJavaCompilation, SetupCopyFiles etc all use >>>>> the >>>>> same semantics (and same implementation) for finding source files. I'm >>>>> doing >>>>> the work in the sandbox forest in a branch named >>>>> erikj-makefilesets-branch >>>>> if you are interested in checking it out. So far I've converted >>>>> SetupCopyFiles and SetupTextFileProcessing. The common source file >>>>> definitions can be found in the new FileSet.gmk: >>>>> >>>>> >>>>> >>>>> http://hg.openjdk.java.net/jdk9/sandbox/file/7ad550ee1d67/make/common/FileSet.gmk >>>>> >>>>> /Erik >>>>> >>>>> On 2016-01-04 20:26, Volker Simonis wrote: >>>>>> Hi, >>>>>> >>>>>> could someone please review the following small fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8146425/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146425 >>>>>> >>>>>> Change "8142907: Integration of minor fixes from the build-infra >>>>>> project" has introduced a new parameter called EXCLUDE_PATTERN for >>>>>> calls to SetupNativeCompilation. >>>>>> >>>>>> Unfortunately this change also altered the semantics of EXCLUDE_FILE >>>>>> which is now interpreted as a pattern of the form "*EXCLUDE_FILE". >>>>>> This is because of the following code: >>>>>> >>>>>> ifneq ($$($1_ALL_EXCLUDE_FILES),) >>>>>> $1_EXCLUDE_FILES_PAT := $$($1_ALL_EXCLUDE_FILES) \ >>>>>> $$(foreach i,$$($1_SRC),$$(addprefix >>>>>> $$i/,$$($1_ALL_EXCLUDE_FILES))) >>>>>> $1_EXCLUDE_FILES_PAT := $$(addprefix %,$$($1_EXCLUDE_FILES_PAT)) >>>>>> $1_SRCS := $$(filter-out $$($1_EXCLUDE_FILES_PAT),$$($1_SRCS)) >>>>>> >>>>>> $1_EXCLUDE_FILES_PAT is initialized to contain all the simple file >>>>>> names which are to be excluded plus all of these file names prefixed >>>>>> with each src path. In the next step, all the entries in >>>>>> $1_EXCLUDE_FILES_PAT are converted to patterns by prefixing them with >>>>>> the wildcard character "%". Finally, the patterns are matched against >>>>>> all the existing source files. This leads to the problem that every >>>>>> file which was given as EXCLUDE_FILES will be converted into a >>>>>> "%EXCLUDE_FILES" pattern thus effectively excluding not just files >>>>>> with the name EXCLUDE_FILES but actually all files ending in >>>>>> EXCLUDE_FILES. >>>>>> >>>>>> This hit us badly on AIX where we have the implementation file >>>>>> AixNativeThread.c and the exclude NativeThread.c. After change 8142907 >>>>>> AixNativeThread.c was silently excluded from the compilation leading >>>>>> to errors during runtime because the file contained some native >>>>>> methods from sun.nio.ch which are not always used. >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>> From volker.simonis at gmail.com Tue Jan 5 17:50:51 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 5 Jan 2016 18:50:51 +0100 Subject: RFR(XS): 8146425: After change 8142907 'EXCLUDE_FILE' is wrongly interpreted as pattern In-Reply-To: <568C022E.60708@oracle.com> References: <568B8407.4020501@oracle.com> <568B84A5.4020608@oracle.com> <568BF3A6.8060201@oracle.com> <568C022E.60708@oracle.com> Message-ID: Thanks for the fast review Erik. I'll push it now and if I'm lucky enough I'll already fix our nightly builds today :) Regards, Volker On Tue, Jan 5, 2016 at 6:49 PM, Erik Joelsson wrote: > Looks good to me. Thank you Volker! > > I will make sure I don't break this with the upcoming changes. > > /Erik > > > On 2016-01-05 18:42, Volker Simonis wrote: >> >> OK, I only want to get this fixed now. >> >> Do you agree with the new fix which is AIX-only and prepends '/' to >> the filename as suggested by you: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8146425.v1/ >> >> Regards, >> Volker >> >> On Tue, Jan 5, 2016 at 5:47 PM, Erik Joelsson >> wrote: >>> >>> Hello Volker, >>> >>> On 2016-01-05 14:27, Volker Simonis wrote: >>>> >>>> I see, but as far as I understand all you are saying only applies to >>>> the new hotspot-build system in build-infra. So I really don't see why >>>> these changes had to be integrated into jdk9-dev. As far as I can see, >>>> EXCLUDE_PATTERNS isn't currently used anywhere in jdk9-dev. >>> >>> That is correct. We use the functionality in build-infra/jdk9 for the new >>> hotspot build. We integrated a bunch of general build changes early to >>> reduce the burden of maintaining those changes in the build-infra >>> repository. This was one of them. Some were relevant to jdk9, this one >>> wasn't yet. >>>> >>>> And I'm a little reluctant to use '/NativeThread.c' as you proposed >>>> because according to the link you posted this pattern will be >>>> interpreted as an absolute path with the upcoming changes you are >>>> doing. >>> >>> In my changes, I have to change and verify all the includes/excludes >>> everywhere since I'm changing the semantics again. I would promise to >>> keep >>> an extra eye on NativeThread.c. >>>> >>>> What is the actual problem with my fix? I could build without >>>> problems. And I still think EXCLUDE_FILE should just be just a file >>>> name. If you need to exclude a file by name without specifying a >>>> sub-directory you can build such a functionality into the new >>>> EXCLUDE_PATTERNS. >>> >>> The problem is that we now have closed code where we already prepended a >>> slash as part of the change. If you change this behavior back, I will >>> need >>> to quickly fix those closed places too. That is of course Oracle's >>> problem >>> and not OpenJDK's. >>> >>> While I agree that a parameter named "EXCLUDE_FILES" should probably just >>> refer to exact filenames, I find the new semantics more useful, so the >>> error >>> is rather in the parameter name. Also note that SetupJavaCompilation has >>> been working this way all along so this change was also intended to align >>> the semantics between the different macros. >>>> >>>> I really would appreciate a fast resolution of this problem because >>>> all our AIX builds are currently unusable. >>> >>> I certainly understand that. >>> >>> /Erik >>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> >>>> On Tue, Jan 5, 2016 at 9:53 AM, Erik Joelsson >>>> wrote: >>>>> >>>>> >>>>> On 2016-01-05 09:51, Erik Joelsson wrote: >>>>>> >>>>>> Hello Volker, >>>>>> >>>>>> I believe this change in behavior was intended at the time. In an >>>>>> internal >>>>>> situation where the same thing hit us, we changed the exclude pattern >>>>>> in >>>>>> question by adding a slash at the front: '/NativeThread.c'. >>>>>> >>>>> And the reason we needed this change was that we wanted to exclude >>>>> files >>>>> by >>>>> name without having to specify sub directory. Typically in Hotspot, >>>>> there >>>>> are a lot of sub directories with native source. >>>>> >>>>> /Erik >>>>> >>>>>> I should also inform you that I'm currently working on a major >>>>>> overhaul >>>>>> of >>>>>> all the INCLUDE/EXCLUDE file finding mechanisms in the build so that >>>>>> SetupNativeCompilation, SetupJavaCompilation, SetupCopyFiles etc all >>>>>> use >>>>>> the >>>>>> same semantics (and same implementation) for finding source files. I'm >>>>>> doing >>>>>> the work in the sandbox forest in a branch named >>>>>> erikj-makefilesets-branch >>>>>> if you are interested in checking it out. So far I've converted >>>>>> SetupCopyFiles and SetupTextFileProcessing. The common source file >>>>>> definitions can be found in the new FileSet.gmk: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> http://hg.openjdk.java.net/jdk9/sandbox/file/7ad550ee1d67/make/common/FileSet.gmk >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2016-01-04 20:26, Volker Simonis wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> could someone please review the following small fix: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8146425/ >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146425 >>>>>>> >>>>>>> Change "8142907: Integration of minor fixes from the build-infra >>>>>>> project" has introduced a new parameter called EXCLUDE_PATTERN for >>>>>>> calls to SetupNativeCompilation. >>>>>>> >>>>>>> Unfortunately this change also altered the semantics of EXCLUDE_FILE >>>>>>> which is now interpreted as a pattern of the form "*EXCLUDE_FILE". >>>>>>> This is because of the following code: >>>>>>> >>>>>>> ifneq ($$($1_ALL_EXCLUDE_FILES),) >>>>>>> $1_EXCLUDE_FILES_PAT := $$($1_ALL_EXCLUDE_FILES) \ >>>>>>> $$(foreach i,$$($1_SRC),$$(addprefix >>>>>>> $$i/,$$($1_ALL_EXCLUDE_FILES))) >>>>>>> $1_EXCLUDE_FILES_PAT := $$(addprefix >>>>>>> %,$$($1_EXCLUDE_FILES_PAT)) >>>>>>> $1_SRCS := $$(filter-out >>>>>>> $$($1_EXCLUDE_FILES_PAT),$$($1_SRCS)) >>>>>>> >>>>>>> $1_EXCLUDE_FILES_PAT is initialized to contain all the simple file >>>>>>> names which are to be excluded plus all of these file names prefixed >>>>>>> with each src path. In the next step, all the entries in >>>>>>> $1_EXCLUDE_FILES_PAT are converted to patterns by prefixing them with >>>>>>> the wildcard character "%". Finally, the patterns are matched against >>>>>>> all the existing source files. This leads to the problem that every >>>>>>> file which was given as EXCLUDE_FILES will be converted into a >>>>>>> "%EXCLUDE_FILES" pattern thus effectively excluding not just files >>>>>>> with the name EXCLUDE_FILES but actually all files ending in >>>>>>> EXCLUDE_FILES. >>>>>>> >>>>>>> This hit us badly on AIX where we have the implementation file >>>>>>> AixNativeThread.c and the exclude NativeThread.c. After change >>>>>>> 8142907 >>>>>>> AixNativeThread.c was silently excluded from the compilation leading >>>>>>> to errors during runtime because the file contained some native >>>>>>> methods from sun.nio.ch which are not always used. >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>> >>>>>> > From tim.bell at oracle.com Tue Jan 5 20:24:29 2016 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 05 Jan 2016 12:24:29 -0800 Subject: RFR: JDK-8146403: Windows build can be faster In-Reply-To: <568BA1D1.2060104@oracle.com> References: <568BA1D1.2060104@oracle.com> Message-ID: <568C267D.6030903@oracle.com> Erik: > During the hotspot makefile conversion, we have been reminded of > inefficiencies when running make in Cygwin. > [... snip ...] > Since these improvements affect much more than just the new hotspot > build, I intend to push this to JDK 9 directly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146403 > Webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.01/ Looks good to me. Thanks for doing this. Tim From rob.mckenna at oracle.com Wed Jan 6 19:12:23 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 6 Jan 2016 19:12:23 +0000 Subject: [8u76] Request for review & approval for CR8146566: OpenJDK build can't handle commas in LDFLAGS In-Reply-To: <849215727.4899968.1452107409827.JavaMail.zimbra@redhat.com> References: <849215727.4899968.1452107409827.JavaMail.zimbra@redhat.com> Message-ID: <568D6717.5010604@oracle.com> cc'ing build-dev for a review and updating the subject. -Rob On 06/01/16 19:10, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8146566 > Webrev: http://cr.openjdk.java.net/~andrew/8u/8146566/webrev.01/ > > If additional LDFLAGS containing commas are passed to the build e.g. > > --with-extra-ldflags="-Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common" > > (which are the default flags on Fedora), then the build will fail as the call to > SetupNativeCompilation expands LDFLAGS_JDKLIB early and the commas are interpreted > to denote separate arguments to this macro. > > On current 8u, this only affects the demo code (BUILD_DEMO_JVMTI_$1). It did > affect both the demo code and the main JDK build on 9, and I was planning > to submit a similar fix there. However, 8142907 was added which fixed both cases > there, as well as introducing a number of other changes. > > For 8u, I'd like to backport the relevant part of 8142907 under this bug, 8146566. > Without this fix, the build fails with the above option. With it, > it successfully completes. 8142907 in full contains other changes, many specific > to Mac OS, which would introduce unnecessary changes into the 8u build. > > Ok to push this? > From erik.joelsson at oracle.com Thu Jan 7 09:17:49 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 7 Jan 2016 10:17:49 +0100 Subject: [8u76] Request for review & approval for CR8146566: OpenJDK build can't handle commas in LDFLAGS In-Reply-To: <568D6717.5010604@oracle.com> References: <849215727.4899968.1452107409827.JavaMail.zimbra@redhat.com> <568D6717.5010604@oracle.com> Message-ID: <568E2D3D.2010009@oracle.com> Looks good. /Erik On 2016-01-06 20:12, Rob McKenna wrote: > cc'ing build-dev for a review and updating the subject. > > -Rob > > On 06/01/16 19:10, Andrew Hughes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8146566 >> Webrev: http://cr.openjdk.java.net/~andrew/8u/8146566/webrev.01/ >> >> If additional LDFLAGS containing commas are passed to the build e.g. >> >> --with-extra-ldflags="-Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu >> -Wl,--sort-common" >> >> (which are the default flags on Fedora), then the build will fail as >> the call to >> SetupNativeCompilation expands LDFLAGS_JDKLIB early and the commas >> are interpreted >> to denote separate arguments to this macro. >> >> On current 8u, this only affects the demo code (BUILD_DEMO_JVMTI_$1). >> It did >> affect both the demo code and the main JDK build on 9, and I was >> planning >> to submit a similar fix there. However, 8142907 was added which fixed >> both cases >> there, as well as introducing a number of other changes. >> >> For 8u, I'd like to backport the relevant part of 8142907 under this >> bug, 8146566. >> Without this fix, the build fails with the above option. With it, >> it successfully completes. 8142907 in full contains other changes, >> many specific >> to Mac OS, which would introduce unnecessary changes into the 8u build. >> >> Ok to push this? >> From volker.simonis at gmail.com Thu Jan 7 19:00:38 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Jan 2016 20:00:38 +0100 Subject: RFR(S): 8146638: Only use compiler option files if they are really supported by the toolchain Message-ID: Hi, can somebody please review and sponsor (needs regeneration of generated-configure.sh because of closed sources) the following small fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8146638/ https://bugs.openjdk.java.net/browse/JDK-8146638 Older versions of gcc don't support the '@file' syntax for passing options to the compiler trough an options file. So better check during the configuration phase if gcc supports the '@file' syntax and configure the make appropriately. Inside NativeCompilation.gmk we now only use compiler option files if COMPILER_COMMAND_FILE_FLAG was defined during the configure process (instead of explicitly checking for the sstudio toolchain which doesn't support compiler option files as well). Tested with old/new GCC which don't/support @file and on Solaris to verify the nothing has been broken. Thank you and best regards, Volker From volker.simonis at gmail.com Thu Jan 7 19:06:17 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Jan 2016 20:06:17 +0100 Subject: RFR(S): 8146639: Fix detection of Cups headers during configuration Message-ID: Hi, can somebody please review and sponsor (needs regeneration of generated-configure.sh because of closed sources) the following small fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8146639/ https://bugs.openjdk.java.net/browse/JDK-8146639 Currently, if the location of the Cups headers is passed to configure via the --with-cups or --with-cups-inlcude option, the locations are not checked to really contain the required Cups header files. This will lead to a compilation error, if there are no Cups header files in the default include path. Even worse, if the user wants to specify special versions of the Cups header files via the --with-cups or --with-cups-inlcude options but mis-types the path while there exist Cups header files in the standard include path, the standard headers will be used silently (because the location given by --with-cups or --with-cups-inlcude isn't checked and rejected.) Thank you and best regards, Volker From erik.joelsson at oracle.com Fri Jan 8 08:38:46 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Jan 2016 09:38:46 +0100 Subject: RFR(S): 8146638: Only use compiler option files if they are really supported by the toolchain In-Reply-To: References: Message-ID: <568F7596.9000901@oracle.com> Change looks good to me. I will sponsor it. /Erik On 2016-01-07 20:00, Volker Simonis wrote: > Hi, > > can somebody please review and sponsor (needs regeneration of > generated-configure.sh because of closed sources) the following small > fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8146638/ > https://bugs.openjdk.java.net/browse/JDK-8146638 > > Older versions of gcc don't support the '@file' syntax for passing > options to the compiler trough an options file. > > So better check during the configuration phase if gcc supports the > '@file' syntax and configure the make appropriately. > > Inside NativeCompilation.gmk we now only use compiler option files if > COMPILER_COMMAND_FILE_FLAG was defined during the configure process > (instead of explicitly checking for the sstudio toolchain which > doesn't support compiler option files as well). > > Tested with old/new GCC which don't/support @file and on Solaris to > verify the nothing has been broken. > > Thank you and best regards, > Volker From erik.joelsson at oracle.com Fri Jan 8 08:41:41 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Jan 2016 09:41:41 +0100 Subject: RFR(S): 8146639: Fix detection of Cups headers during configuration In-Reply-To: References: Message-ID: <568F7645.9030402@oracle.com> Nice fix, but it looks like a typo in libs-cups.m4 line 62. I think it should be ${with_cups_include}/cups/cups.h. /Erik On 2016-01-07 20:06, Volker Simonis wrote: > Hi, > > can somebody please review and sponsor (needs regeneration of > generated-configure.sh because of closed sources) the following small > fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8146639/ > https://bugs.openjdk.java.net/browse/JDK-8146639 > > Currently, if the location of the Cups headers is passed to configure > via the --with-cups or --with-cups-inlcude option, the locations are > not checked to really contain the required Cups header files. This > will lead to a compilation error, if there are no Cups header files in > the default include path. > > Even worse, if the user wants to specify special versions of the Cups > header files via the --with-cups or --with-cups-inlcude options but > mis-types the path while there exist Cups header files in the standard > include path, the standard headers will be used silently (because the > location given by --with-cups or --with-cups-inlcude isn't checked and > rejected.) > > Thank you and best regards, > Volker From volker.simonis at gmail.com Fri Jan 8 09:36:15 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 8 Jan 2016 10:36:15 +0100 Subject: RFR(S): 8146638: Only use compiler option files if they are really supported by the toolchain In-Reply-To: <568F7596.9000901@oracle.com> References: <568F7596.9000901@oracle.com> Message-ID: Thanks a lot Erik! On Fri, Jan 8, 2016 at 9:38 AM, Erik Joelsson wrote: > Change looks good to me. I will sponsor it. > > /Erik > > > On 2016-01-07 20:00, Volker Simonis wrote: >> >> Hi, >> >> can somebody please review and sponsor (needs regeneration of >> generated-configure.sh because of closed sources) the following small >> fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8146638/ >> https://bugs.openjdk.java.net/browse/JDK-8146638 >> >> Older versions of gcc don't support the '@file' syntax for passing >> options to the compiler trough an options file. >> >> So better check during the configuration phase if gcc supports the >> '@file' syntax and configure the make appropriately. >> >> Inside NativeCompilation.gmk we now only use compiler option files if >> COMPILER_COMMAND_FILE_FLAG was defined during the configure process >> (instead of explicitly checking for the sstudio toolchain which >> doesn't support compiler option files as well). >> >> Tested with old/new GCC which don't/support @file and on Solaris to >> verify the nothing has been broken. >> >> Thank you and best regards, >> Volker > > From volker.simonis at gmail.com Fri Jan 8 09:47:05 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 8 Jan 2016 10:47:05 +0100 Subject: RFR(S): 8146639: Fix detection of Cups headers during configuration In-Reply-To: <568F7645.9030402@oracle.com> References: <568F7645.9030402@oracle.com> Message-ID: You're of course right. Good catch! Here's the new version (I've also updated the copyright year since we're already in 2016 :) http://cr.openjdk.java.net/~simonis/webrevs/2016/8146639.v1/ Thank you and best regards, Volker On Fri, Jan 8, 2016 at 9:41 AM, Erik Joelsson wrote: > Nice fix, but it looks like a typo in libs-cups.m4 line 62. I think it > should be ${with_cups_include}/cups/cups.h. > > /Erik > > > On 2016-01-07 20:06, Volker Simonis wrote: >> >> Hi, >> >> can somebody please review and sponsor (needs regeneration of >> generated-configure.sh because of closed sources) the following small >> fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8146639/ >> https://bugs.openjdk.java.net/browse/JDK-8146639 >> >> Currently, if the location of the Cups headers is passed to configure >> via the --with-cups or --with-cups-inlcude option, the locations are >> not checked to really contain the required Cups header files. This >> will lead to a compilation error, if there are no Cups header files in >> the default include path. >> >> Even worse, if the user wants to specify special versions of the Cups >> header files via the --with-cups or --with-cups-inlcude options but >> mis-types the path while there exist Cups header files in the standard >> include path, the standard headers will be used silently (because the >> location given by --with-cups or --with-cups-inlcude isn't checked and >> rejected.) >> >> Thank you and best regards, >> Volker > > From erik.joelsson at oracle.com Fri Jan 8 10:01:45 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Jan 2016 11:01:45 +0100 Subject: RFR(S): 8146639: Fix detection of Cups headers during configuration In-Reply-To: References: <568F7645.9030402@oracle.com> Message-ID: <568F8909.2070204@oracle.com> Looks good. Will push. /Erik On 2016-01-08 10:47, Volker Simonis wrote: > You're of course right. Good catch! > > Here's the new version (I've also updated the copyright year since > we're already in 2016 :) > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8146639.v1/ > > Thank you and best regards, > Volker > > > On Fri, Jan 8, 2016 at 9:41 AM, Erik Joelsson wrote: >> Nice fix, but it looks like a typo in libs-cups.m4 line 62. I think it >> should be ${with_cups_include}/cups/cups.h. >> >> /Erik >> >> >> On 2016-01-07 20:06, Volker Simonis wrote: >>> Hi, >>> >>> can somebody please review and sponsor (needs regeneration of >>> generated-configure.sh because of closed sources) the following small >>> fix: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8146639/ >>> https://bugs.openjdk.java.net/browse/JDK-8146639 >>> >>> Currently, if the location of the Cups headers is passed to configure >>> via the --with-cups or --with-cups-inlcude option, the locations are >>> not checked to really contain the required Cups header files. This >>> will lead to a compilation error, if there are no Cups header files in >>> the default include path. >>> >>> Even worse, if the user wants to specify special versions of the Cups >>> header files via the --with-cups or --with-cups-inlcude options but >>> mis-types the path while there exist Cups header files in the standard >>> include path, the standard headers will be used silently (because the >>> location given by --with-cups or --with-cups-inlcude isn't checked and >>> rejected.) >>> >>> Thank you and best regards, >>> Volker >> From magnus.ihse.bursie at oracle.com Fri Jan 8 13:35:52 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 8 Jan 2016 14:35:52 +0100 Subject: JDK-8146091: Configure fails to configure icecc on OEL In-Reply-To: <567A8D9C.1010206@oracle.com> References: <567A8D9C.1010206@oracle.com> Message-ID: <568FBB38.602@oracle.com> Looks good to me. /Magnus On 2015-12-23 13:03, Erik Joelsson wrote: > Hello, > > The icecc-create-env utility in older icecc distributions takes input > parameters differently. On my Ubuntu: > > $ /usr/lib/icecc/icecc-create-env > usage: /usr/lib/icecc/icecc-create-env --gcc > usage: /usr/lib/icecc/icecc-create-env --clang > > usage: Use --addfile to add extra files. > > On an OEL: > $ /usr/lib64/icecc/icecc-create-env > usage: /usr/lib64/icecc/icecc-create-env > > Testing for which format is needed is pretty simple. If there is a > "--gcc" in th help text, then we need to set --gcc. > > I also added several checks so that configure fails when the icecc > build environment cannot be built. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146091 > Webrev: http://cr.openjdk.java.net/~erikj/8146091/webrev.01/ > > /Erik From gnu.andrew at redhat.com Fri Jan 8 13:56:23 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 8 Jan 2016 08:56:23 -0500 (EST) Subject: [8u76] Request for review & approval for CR8146566: OpenJDK build can't handle commas in LDFLAGS In-Reply-To: <568E2D3D.2010009@oracle.com> References: <849215727.4899968.1452107409827.JavaMail.zimbra@redhat.com> <568D6717.5010604@oracle.com> <568E2D3D.2010009@oracle.com> Message-ID: <775074092.5862345.1452261383501.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Looks good. > > /Erik > Thanks Erik. Pushed: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/92c6a16b6dac > On 2016-01-06 20:12, Rob McKenna wrote: > > cc'ing build-dev for a review and updating the subject. > > > > -Rob > > > > On 06/01/16 19:10, Andrew Hughes wrote: > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8146566 > >> Webrev: http://cr.openjdk.java.net/~andrew/8u/8146566/webrev.01/ > >> > >> If additional LDFLAGS containing commas are passed to the build e.g. > >> > >> --with-extra-ldflags="-Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu > >> -Wl,--sort-common" > >> > >> (which are the default flags on Fedora), then the build will fail as > >> the call to > >> SetupNativeCompilation expands LDFLAGS_JDKLIB early and the commas > >> are interpreted > >> to denote separate arguments to this macro. > >> > >> On current 8u, this only affects the demo code (BUILD_DEMO_JVMTI_$1). > >> It did > >> affect both the demo code and the main JDK build on 9, and I was > >> planning > >> to submit a similar fix there. However, 8142907 was added which fixed > >> both cases > >> there, as well as introducing a number of other changes. > >> > >> For 8u, I'd like to backport the relevant part of 8142907 under this > >> bug, 8146566. > >> Without this fix, the build fails with the above option. With it, > >> it successfully completes. 8142907 in full contains other changes, > >> many specific > >> to Mac OS, which would introduce unnecessary changes into the 8u build. > >> > >> Ok to push this? > >> > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From rob.mckenna at oracle.com Fri Jan 8 15:29:30 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 8 Jan 2016 15:29:30 +0000 Subject: [8u76] Request for review & approval for CR8146566: OpenJDK build can't handle commas in LDFLAGS In-Reply-To: <775074092.5862345.1452261383501.JavaMail.zimbra@redhat.com> References: <849215727.4899968.1452107409827.JavaMail.zimbra@redhat.com> <568D6717.5010604@oracle.com> <568E2D3D.2010009@oracle.com> <775074092.5862345.1452261383501.JavaMail.zimbra@redhat.com> Message-ID: <568FD5DA.8000403@oracle.com> Approved. (not sure why I didn't explicitly state that in the last mail) -Rob On 08/01/16 13:56, Andrew Hughes wrote: > ----- Original Message ----- >> Looks good. >> >> /Erik >> > > Thanks Erik. Pushed: > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/92c6a16b6dac > >> On 2016-01-06 20:12, Rob McKenna wrote: >>> cc'ing build-dev for a review and updating the subject. >>> >>> -Rob >>> >>> On 06/01/16 19:10, Andrew Hughes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146566 >>>> Webrev: http://cr.openjdk.java.net/~andrew/8u/8146566/webrev.01/ >>>> >>>> If additional LDFLAGS containing commas are passed to the build e.g. >>>> >>>> --with-extra-ldflags="-Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu >>>> -Wl,--sort-common" >>>> >>>> (which are the default flags on Fedora), then the build will fail as >>>> the call to >>>> SetupNativeCompilation expands LDFLAGS_JDKLIB early and the commas >>>> are interpreted >>>> to denote separate arguments to this macro. >>>> >>>> On current 8u, this only affects the demo code (BUILD_DEMO_JVMTI_$1). >>>> It did >>>> affect both the demo code and the main JDK build on 9, and I was >>>> planning >>>> to submit a similar fix there. However, 8142907 was added which fixed >>>> both cases >>>> there, as well as introducing a number of other changes. >>>> >>>> For 8u, I'd like to backport the relevant part of 8142907 under this >>>> bug, 8146566. >>>> Without this fix, the build fails with the above option. With it, >>>> it successfully completes. 8142907 in full contains other changes, >>>> many specific >>>> to Mac OS, which would introduce unnecessary changes into the 8u build. >>>> >>>> Ok to push this? >>>> >> >> > From david.holmes at oracle.com Tue Jan 12 07:30:13 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jan 2016 17:30:13 +1000 Subject: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds. In-Reply-To: <566AE88C.3040701@oracle.com> References: <566AE88C.3040701@oracle.com> Message-ID: <5694AB85.9040509@oracle.com> Hi Gary, I mainly looked at the hotspot files, but not everything in detail. Some issues will change when this sync's up with mainline again. Overall a lot of things making me cringe. Cheers, David --- hotspot/make/Makefile Isn't a JIT-less VM a ZERO build? Otherwise if we really want CORE then we should make CORE work. --- hotspot/make/bsd/makefiles/dtrace.make Please make sure the comments are updated to reflect the code eg: 27 # We build libjvm_dtrace/libjvm_db/dtrace for COMPILER1 and COMPILER2 28 # but not for CORE configuration. 29 30 ifneq ("${TYPE}", "CORE") 31 ifneq ("${TYPE}", "MINIMAL1") 32 ifneq ($(OPENJDK_TARGET_OS), ios) line 28 needs updating. I'd also like to see indentation of conditional code if possible. 329 else # IPHONE build There is no "if" that references IPHONE build - is this really the iOS part? --- hotspot/make/bsd/makefiles/minimal1.make hotspot/make/linux/makefiles/minimal1.make This seems to be a new definition of the minimal VM which now includes JVM TI ?? Not sure the minimal VM should mean different things on different platforms. Also unclear if you can really enable JVM TI with all the other "minimal" components disabled - it was never intended/allowed-for an arbitrary subset of INCLUDE_XXX flags to be turned on/off. --- hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp hotspot/src/cpu/x86/vm/c1_Runtime1_x86.cpp etc Without more context the change of casts from intptr_t to int32_t, or added cast of int32_t seem wrong - they should be 64-bit on a 64-bit platform. If this is all actually 32-bit only code then a lot of other changes can/should be made regarding the LP64 macros. Regardless if the type of NULL_WORD is causing a problem then its type should be fixed, not added casts everywhere it is used. --- hotspot/src/os/linux/vm/jvm_linux.cpp Shouldn't this: + #ifdef __ANDROID__ + // Android 'h' files don't have a define for SIGCLD + // I therefore took the following define & comment from Linux's + // /usr/include/bits/signum.h + #define SIGCLD SIGCHLD /* Same as SIGCHLD (System V). */ + #endif "CLD", SIGCLD, /* Same as SIGCHLD (System V). */ "CHLD", SIGCHLD, /* Child status has changed (POSIX). */ just be: + #ifdef SIGCLD "CLD", SIGCLD, /* Same as SIGCHLD (System V). */ +#endif "CHLD", SIGCHLD, /* Child status has changed (POSIX). */ --- hotspot/src/os/linux/vm/os_linux.cpp (and others) Is the need for all the _ANDROID_ conditionals due to this not being Linux or not having glibc? We actually want to get rid of the dlsym dynamic lookup in mainline because we no longer support Linux versions without the desired functions! Overall the conditionals here make this code really ugly/messy. :( --- hotspot/src/share/vm/prims/jvm.cpp Really hate the android conditionals in this shared code! --- hotspot/src/share/vm/prims/jvmtiExport.cpp Not at all clear to me that the code conditionalized belongs to SERVICES! Is this just a hack to exclude attach-on-demand? --- hotspot/src/share/vm/runtime/java.cpp Would want to look at ways to make this cleaner. --- hotspot/src/share/vm/runtime/orderAccess.inline.hpp These changes are ugly and should not be necessary - needs further examination. The whole point of intptr_t is that it will the same as int on 32-bit (ILP32), and same as a pointer on 64-bit (LP64). Is Android/iOS defining a different programming model? On 12/12/2015 1:15 AM, Gary Adams wrote: > Here's the initial upload of changes that provides support for the ios > and android ports > for the mobile/dev repos. While there have been some preliminary reviews > of the code, > there is still more work required before we will look for more thorough > reviews > and an integration to mobile/jdk9 repos. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8145132 > Webrev: http://cr.openjdk.java.net/~gadams/8145132/webrev.00/ > > > Here's a simple configure script to generate a ios-x86_64 build for use > with the iphone simulator. (uses homebrew 64 bit freetype from pkgconfig) > > export JAVA_HOME=`/usr/libexec/java_home -v 1.8` > export PATH=$JAVA_HOME/bin:~/homebrew/bin:$PATH > > bash ../../configure \ > --openjdk-target=x86_64-macos-ios \ > --with-boot-jdk=$JAVA_HOME \ > --disable-warnings-as-errors \ > --disable-headful \ > --enable-static-build=yes \ > --with-jvm-variants=minimal1 > > > Also, tested with i586-macos-ios target for 32 bit > with a locally built --with-freetype 2.6.2. From gary.adams at oracle.com Tue Jan 12 12:49:20 2016 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 12 Jan 2016 07:49:20 -0500 Subject: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds. In-Reply-To: <5694AB85.9040509@oracle.com> References: <566AE88C.3040701@oracle.com> <5694AB85.9040509@oracle.com> Message-ID: <5694F650.8060606@oracle.com> On 01/12/16 02:30, David Holmes wrote: > Hi Gary, > > I mainly looked at the hotspot files, but not everything in detail. > Some issues will change when this sync's up with mainline again. > > Overall a lot of things making me cringe. > > Cheers, > David > > --- > > hotspot/make/Makefile > > Isn't a JIT-less VM a ZERO build? Otherwise if we really want CORE > then we should make CORE work. I'll leave the zero versus core vm question to Bob. If I recall correctly neither was being maintained and tested on a regular basis, and the zero only required minimal updates to get up and running on ios platform. > > --- > > hotspot/make/bsd/makefiles/dtrace.make > > Please make sure the comments are updated to reflect the code eg: > > 27 # We build libjvm_dtrace/libjvm_db/dtrace for COMPILER1 and > COMPILER2 > 28 # but not for CORE configuration. > 29 > 30 ifneq ("${TYPE}", "CORE") > 31 ifneq ("${TYPE}", "MINIMAL1") > 32 ifneq ($(OPENJDK_TARGET_OS), ios) > > line 28 needs updating. I'd also like to see indentation of > conditional code if possible. We held off on indentation changes, since the hotspot makefiles had not been updated for the new build guidelines. > > 329 else # IPHONE build > > There is no "if" that references IPHONE build - is this really the iOS > part? > > --- > > hotspot/make/bsd/makefiles/minimal1.make > hotspot/make/linux/makefiles/minimal1.make > > This seems to be a new definition of the minimal VM which now includes > JVM TI ?? Not sure the minimal VM should mean different things on > different platforms. Also unclear if you can really enable JVM TI with > all the other "minimal" components disabled - it was never > intended/allowed-for an arbitrary subset of INCLUDE_XXX flags to be > turned on/off. I'll leave this for Bob to address. We initially were supporting minimal and client vm for ios, but found our users only needing the jvmti features from the client vm. > > --- > > hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > hotspot/src/cpu/x86/vm/c1_Runtime1_x86.cpp > etc > > Without more context the change of casts from intptr_t to int32_t, or > added cast of int32_t seem wrong - they should be 64-bit on a 64-bit > platform. If this is all actually 32-bit only code then a lot of other > changes can/should be made regarding the LP64 macros. Regardless if > the type of NULL_WORD is causing a problem then its type should be > fixed, not added casts everywhere it is used. I'll leave this to Bertrand to address. I'll leave the remaining android impl questions to Bob. Our android developer is no longer with us, so we will have some work to do before these initial code changes are acceptable for mainstream integration. > > --- > > hotspot/src/os/linux/vm/jvm_linux.cpp > > Shouldn't this: > > + #ifdef __ANDROID__ > + // Android 'h' files don't have a define for SIGCLD > + // I therefore took the following define & comment from Linux's > + // /usr/include/bits/signum.h > + #define SIGCLD SIGCHLD /* Same as SIGCHLD (System V). */ > + #endif > "CLD", SIGCLD, /* Same as SIGCHLD (System V). */ > "CHLD", SIGCHLD, /* Child status has changed > (POSIX). */ > > just be: > > + #ifdef SIGCLD > "CLD", SIGCLD, /* Same as SIGCHLD (System V). */ > +#endif > "CHLD", SIGCHLD, /* Child status has changed > (POSIX). */ > > --- > > hotspot/src/os/linux/vm/os_linux.cpp (and others) > > Is the need for all the _ANDROID_ conditionals due to this not being > Linux or not having glibc? We actually want to get rid of the dlsym > dynamic lookup in mainline because we no longer support Linux versions > without the desired functions! > > Overall the conditionals here make this code really ugly/messy. :( > > --- > > hotspot/src/share/vm/prims/jvm.cpp > > Really hate the android conditionals in this shared code! > > --- > > hotspot/src/share/vm/prims/jvmtiExport.cpp > > Not at all clear to me that the code conditionalized belongs to > SERVICES! Is this just a hack to exclude attach-on-demand? > --- > > hotspot/src/share/vm/runtime/java.cpp > > Would want to look at ways to make this cleaner. > > --- > > hotspot/src/share/vm/runtime/orderAccess.inline.hpp > > These changes are ugly and should not be necessary - needs further > examination. The whole point of intptr_t is that it will the same as > int on 32-bit (ILP32), and same as a pointer on 64-bit (LP64). Is > Android/iOS defining a different programming model? > > > > On 12/12/2015 1:15 AM, Gary Adams wrote: >> Here's the initial upload of changes that provides support for the ios >> and android ports >> for the mobile/dev repos. While there have been some preliminary reviews >> of the code, >> there is still more work required before we will look for more thorough >> reviews >> and an integration to mobile/jdk9 repos. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8145132 >> Webrev: http://cr.openjdk.java.net/~gadams/8145132/webrev.00/ >> >> >> Here's a simple configure script to generate a ios-x86_64 build for use >> with the iphone simulator. (uses homebrew 64 bit freetype from >> pkgconfig) >> >> export JAVA_HOME=`/usr/libexec/java_home -v 1.8` >> export PATH=$JAVA_HOME/bin:~/homebrew/bin:$PATH >> >> bash ../../configure \ >> --openjdk-target=x86_64-macos-ios \ >> --with-boot-jdk=$JAVA_HOME \ >> --disable-warnings-as-errors \ >> --disable-headful \ >> --enable-static-build=yes \ >> --with-jvm-variants=minimal1 >> >> >> Also, tested with i586-macos-ios target for 32 bit >> with a locally built --with-freetype 2.6.2. From magnus.ihse.bursie at oracle.com Wed Jan 13 11:48:31 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 13 Jan 2016 12:48:31 +0100 Subject: RFR: JDK-8146403: Windows build can be faster In-Reply-To: <568BA1D1.2060104@oracle.com> References: <568BA1D1.2060104@oracle.com> Message-ID: <5696398F.8040706@oracle.com> Hi, In InitSupport.gmk, please restore the comment: # Only do this if make has not been restarted, and if we do not force it. In jdk/make/gensrc/GensrcExceptions.gmk: The old construct resulted in the output "Generating exceptions classes" (but a bit irregularly), could you please re-add it as a LogInfo? In make/CompileTools.gmk, the copyright header says 2014, which is at least one year too early. :-) (In fact, all modified files should really get bumped to 2016). Apart from this, it looks good to me. /Magnus On 2016-01-05 11:58, Erik Joelsson wrote: > Hello, > > During the hotspot makefile conversion, we have been reminded of > inefficiencies when running make in Cygwin. We still have a pretty > severe performance regression in the new hotspot build compared to the > old on Windows in certain situations, my laptop being one such > situation. A recent comparison there between just the old and new > hotspot build: > > release new 00:04:30 > release old 00:03:10 > fastdebug new 00:04:59 > fastdebug old 00:03:37 > > Much of the extra time is spent spawning various shell processes for > book keeping, like saving failure logs, creating header dependency > files etc. > > It also takes a very long time to do a "do nothing" rebuild when > nothing has changed. On my laptop, repeating "make jimages" often > takes as long as 40 seconds to figure out that nothing needs to be > rebuilt. In this case there are several culprits. > > I have been working on improvements in these areas to reduce the > overhead. The "do nothing" rebuild of jimages is down to around 25 > seconds. A full images build is around 1-2 minutes faster from 24 to > 22 minutes, but fluctuates quite a bit. The new hotspot build is also > improved: > > release: 3:44 > fastdebug: 4:02 > > Here is a list of the kinds of changes I've made: > > * Rewrote logger.sh to use a different construct. It drastically > reduces the number of bash processes being spawned. Basically you can > pipe like this: "> >(tee logfile) 2> >(tee logfile >&2)". I also > managed to reduce the extra sed/grep commands needed for the header > dependencies even more. A side effect of this is that the log files > for each native compilation unit are always saved instead of being > deleted on successful compilation. I see no issue with this. > > * Changed all recipes that contain echo for logging to instead use new > LogInfo macro, which in turn calls $(info ) if appropriate. > > * Changed all recipes that contain mkdir to instead use MakeDir macro, > which only executes mkdir if the directory doesn't exist. > > * In HotspotWrapper.gmk there is an optimization to avoid calling the > hotspot makefiles at all if nothing has changed. This runs a find over > the whole hotspot repository. I reduced this to only run over src and > make sub dirs to avoid the pretty large test dir (since test/closed > has grown quite a bit). > > * Split Tools.gmk into CompileTools.gmk and Tools.gmk, to avoid having > the buildtools compilation being reevaluated by all makefiles needing > the tools definitions. > > * Split Modules.gmk to avoid having the module deps generation being > reevaluated multiple times. Made the new GenerateModuleDeps.gmk an > explicit call from Init.gmk. > > Since these improvements affect much more than just the new hotspot > build, I intend to push this to JDK 9 directly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146403 > Webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.01/ > > /Erik From erik.joelsson at oracle.com Wed Jan 13 12:09:21 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Jan 2016 13:09:21 +0100 Subject: RFR(XS): 8146979: Backport of 8046471 breaks ppc64 build in jdk8u because 8072383 was badly backported before In-Reply-To: <56963B9C.2040605@oracle.com> References: <56963B9C.2040605@oracle.com> Message-ID: <56963E71.4000508@oracle.com> Looks good to me. /Erik On 2016-01-13 12:57, david buck wrote: > Approved with the condition that peer code review is approved before > pushing. If the review is done on a different OpenJDK alias, please > send a link for that review thread to this thread before pushing. > > Cheers, > -Buck > > On 2016/01/13 20:40, Volker Simonis wrote: >> Hi, >> >> I please need an urgent review for this little patch in jdk8u-dev >> which fixes a build problem on ppc64. >> >> Can I push this myself directly to >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot ? >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8146979/ >> https://bugs.openjdk.java.net/browse/JDK-8146979 >> >> Recently the change "8046471: Use OPENJDK_TARGET_CPU_ARCH instead of >> legacy value for hotspot ARCH" was backporeted to jdk8u. It changes >> the ARCH value which is passed from the top-level configure to the >> hotspot make via the hotspot-spec.gmk file. For the ppc64 architecture >> this changes the reported value for ARCH from 'ppc64' to 'ppc'. >> >> In jdk9 this is no problem, because the hotspot makefiles correctly >> handle this value. Unfortunately in jdk8u this is not the case, >> because the change "8072383: resolve conflicts between open and closed >> ports" hasn't been correctly downported from jdk9 to jdk8u before. >> >> In jdk9 it contains the following lines: >> >> - SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc >> ppc64 aarch64 zero,$(ARCH))) >> + SRCARCH ?= $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 ppc ppc64 >> aarch64 zero,$(ARCH))) >> >> ARCH/ppc64 = ppc >> ARCH/ppc = ppc >> - ARCH/arm = arm >> ARCH/aarch64= aarch64 >> >> but in the downport this was for whatever reason changed to: >> >> - SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc >> ppc64 zero,$(ARCH))) >> + SRCARCH ?= $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 ppc64 >> zero,$(ARCH))) >> >> ARCH/ppc64 = ppc >> - ARCH/ppc = ppc >> - ARCH/arm = arm >> ARCH/zero = zero >> >> Notice how in jdk8u 'ppc' was removed from SRCARCH and how the line >> 'ARCH/ppc = ppc' was completely deleted in jdk8u. >> >> We need to fix these two line in jdk8u in order to make the build work >> again on ppc64. >> >> Regards, >> Volker >> From erik.helin at oracle.com Wed Jan 13 12:47:07 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 13 Jan 2016 13:47:07 +0100 Subject: RFR: 8146871: Make the clean target silent in hotspot/test/Makefile Message-ID: <20160113124707.GD17653@ehelin.jrpg.bea.com> Hi all, this very small patches silences the 'clean' target in hotspot/test/Makefile (the 'prep' target is already silent). Enhancement: https://bugs.openjdk.java.net/browse/JDK-8146871 Webrev: http://cr.openjdk.java.net/~ehelin/8146871/00/webrev/ Testing: - Buiding locally and verified that the commands are no longer listed - JPRT Thanks, Erik From erik.joelsson at oracle.com Wed Jan 13 13:44:57 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Jan 2016 14:44:57 +0100 Subject: RFR: JDK-8146403: Windows build can be faster In-Reply-To: <5696398F.8040706@oracle.com> References: <568BA1D1.2060104@oracle.com> <5696398F.8040706@oracle.com> Message-ID: <569654D9.2090904@oracle.com> Hello, New webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.02/ Fixed the below comments. Also adjusted some more gensrc log output to make it more uniform, even if it doesn't exactly address Windows performance. I also fixed a bug in the bootstrap make logic. The module-deps.gmk wasn't correctly generated in all cases. Typically when building more than one conf at a time or when doing a compare build. I added explicit calls to GenerateModuleDeps.gmk to fix this. /Erik On 2016-01-13 12:48, Magnus Ihse Bursie wrote: > Hi, > > In InitSupport.gmk, please restore the comment: > # Only do this if make has not been restarted, and if we do not force > it. > > In jdk/make/gensrc/GensrcExceptions.gmk: > The old construct resulted in the output "Generating exceptions > classes" (but a bit irregularly), could you please re-add it as a > LogInfo? > > In make/CompileTools.gmk, the copyright header says 2014, which is at > least one year too early. :-) (In fact, all modified files should > really get bumped to 2016). > > Apart from this, it looks good to me. > > /Magnus > > On 2016-01-05 11:58, Erik Joelsson wrote: >> Hello, >> >> During the hotspot makefile conversion, we have been reminded of >> inefficiencies when running make in Cygwin. We still have a pretty >> severe performance regression in the new hotspot build compared to >> the old on Windows in certain situations, my laptop being one such >> situation. A recent comparison there between just the old and new >> hotspot build: >> >> release new 00:04:30 >> release old 00:03:10 >> fastdebug new 00:04:59 >> fastdebug old 00:03:37 >> >> Much of the extra time is spent spawning various shell processes for >> book keeping, like saving failure logs, creating header dependency >> files etc. >> >> It also takes a very long time to do a "do nothing" rebuild when >> nothing has changed. On my laptop, repeating "make jimages" often >> takes as long as 40 seconds to figure out that nothing needs to be >> rebuilt. In this case there are several culprits. >> >> I have been working on improvements in these areas to reduce the >> overhead. The "do nothing" rebuild of jimages is down to around 25 >> seconds. A full images build is around 1-2 minutes faster from 24 to >> 22 minutes, but fluctuates quite a bit. The new hotspot build is also >> improved: >> >> release: 3:44 >> fastdebug: 4:02 >> >> Here is a list of the kinds of changes I've made: >> >> * Rewrote logger.sh to use a different construct. It drastically >> reduces the number of bash processes being spawned. Basically you can >> pipe like this: "> >(tee logfile) 2> >(tee logfile >&2)". I also >> managed to reduce the extra sed/grep commands needed for the header >> dependencies even more. A side effect of this is that the log files >> for each native compilation unit are always saved instead of being >> deleted on successful compilation. I see no issue with this. >> >> * Changed all recipes that contain echo for logging to instead use >> new LogInfo macro, which in turn calls $(info ) if appropriate. >> >> * Changed all recipes that contain mkdir to instead use MakeDir >> macro, which only executes mkdir if the directory doesn't exist. >> >> * In HotspotWrapper.gmk there is an optimization to avoid calling the >> hotspot makefiles at all if nothing has changed. This runs a find >> over the whole hotspot repository. I reduced this to only run over >> src and make sub dirs to avoid the pretty large test dir (since >> test/closed has grown quite a bit). >> >> * Split Tools.gmk into CompileTools.gmk and Tools.gmk, to avoid >> having the buildtools compilation being reevaluated by all makefiles >> needing the tools definitions. >> >> * Split Modules.gmk to avoid having the module deps generation being >> reevaluated multiple times. Made the new GenerateModuleDeps.gmk an >> explicit call from Init.gmk. >> >> Since these improvements affect much more than just the new hotspot >> build, I intend to push this to JDK 9 directly. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8146403 >> Webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.01/ >> >> /Erik > From volker.simonis at gmail.com Wed Jan 13 13:58:00 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 13 Jan 2016 14:58:00 +0100 Subject: RFR(XS): 8146979: Backport of 8046471 breaks ppc64 build in jdk8u because 8072383 was badly backported before In-Reply-To: <56963E71.4000508@oracle.com> References: <56963B9C.2040605@oracle.com> <56963E71.4000508@oracle.com> Message-ID: Thanks David and Erik! On Wed, Jan 13, 2016 at 1:09 PM, Erik Joelsson wrote: > Looks good to me. > > /Erik > > > On 2016-01-13 12:57, david buck wrote: >> >> Approved with the condition that peer code review is approved before >> pushing. If the review is done on a different OpenJDK alias, please send a >> link for that review thread to this thread before pushing. >> >> Cheers, >> -Buck >> >> On 2016/01/13 20:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> I please need an urgent review for this little patch in jdk8u-dev >>> which fixes a build problem on ppc64. >>> >>> Can I push this myself directly to >>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot ? >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8146979/ >>> https://bugs.openjdk.java.net/browse/JDK-8146979 >>> >>> Recently the change "8046471: Use OPENJDK_TARGET_CPU_ARCH instead of >>> legacy value for hotspot ARCH" was backporeted to jdk8u. It changes >>> the ARCH value which is passed from the top-level configure to the >>> hotspot make via the hotspot-spec.gmk file. For the ppc64 architecture >>> this changes the reported value for ARCH from 'ppc64' to 'ppc'. >>> >>> In jdk9 this is no problem, because the hotspot makefiles correctly >>> handle this value. Unfortunately in jdk8u this is not the case, >>> because the change "8072383: resolve conflicts between open and closed >>> ports" hasn't been correctly downported from jdk9 to jdk8u before. >>> >>> In jdk9 it contains the following lines: >>> >>> - SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc >>> ppc64 aarch64 zero,$(ARCH))) >>> + SRCARCH ?= $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 ppc ppc64 >>> aarch64 zero,$(ARCH))) >>> >>> ARCH/ppc64 = ppc >>> ARCH/ppc = ppc >>> - ARCH/arm = arm >>> ARCH/aarch64= aarch64 >>> >>> but in the downport this was for whatever reason changed to: >>> >>> - SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc >>> ppc64 zero,$(ARCH))) >>> + SRCARCH ?= $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 ppc64 >>> zero,$(ARCH))) >>> >>> ARCH/ppc64 = ppc >>> - ARCH/ppc = ppc >>> - ARCH/arm = arm >>> ARCH/zero = zero >>> >>> Notice how in jdk8u 'ppc' was removed from SRCARCH and how the line >>> 'ARCH/ppc = ppc' was completely deleted in jdk8u. >>> >>> We need to fix these two line in jdk8u in order to make the build work >>> again on ppc64. >>> >>> Regards, >>> Volker >>> > From erik.helin at oracle.com Wed Jan 13 14:01:28 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 13 Jan 2016 15:01:28 +0100 Subject: RFR: Message-ID: <20160113140128.GE17653@ehelin.jrpg.bea.com> Hi all, this patch changes the output directory for hotspot's jtreg tests when run via the top-level Makefile targets such as `make test-hotspot-jtreg`. The current directory is /build//hotspot/linux-x64/testoutput (on an x86-64 machine running Linux). There is no need to place the "testoutput" directory in a directory which name is based on OS and arch, that is already done by the current configuration. Therefore, we can instead place the "testoutput" directory in /build//hotspot/, which is a more reasonable location for the output from hotspot's tests. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8146985 Webrev: http://cr.openjdk.java.net/~ehelin/8146985/00/webrev Testing: - Running `make test-hotspot-jtreg` locally - JPRT (the patch does not affect JPRT since JPRT does not use ALT_OUTPUTDIR) Thanks, Erik From erik.helin at oracle.com Wed Jan 13 14:04:05 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 13 Jan 2016 15:04:05 +0100 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tets to build/conf/hotspot/testoutput In-Reply-To: <20160113140128.GE17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> Message-ID: <20160113140405.GF17653@ehelin.jrpg.bea.com> (added missing subject) On 2016-01-13, Erik Helin wrote: > Hi all, > > this patch changes the output directory for hotspot's jtreg tests when > run via the top-level Makefile targets such as > `make test-hotspot-jtreg`. > > The current directory is > /build//hotspot/linux-x64/testoutput > (on an x86-64 machine running Linux). There is no need to place the > "testoutput" directory in a directory which name is based on OS and arch, > that is already done by the current configuration. Therefore, we can > instead place the "testoutput" directory in > /build//hotspot/, which is a more reasonable location > for the output from hotspot's tests. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8146985 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146985/00/webrev > > Testing: > - Running `make test-hotspot-jtreg` locally > - JPRT (the patch does not affect JPRT since JPRT does not use > ALT_OUTPUTDIR) > > Thanks, > Erik From erik.joelsson at oracle.com Wed Jan 13 14:19:40 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Jan 2016 15:19:40 +0100 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tets to build/conf/hotspot/testoutput In-Reply-To: <20160113140405.GF17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160113140405.GF17653@ehelin.jrpg.bea.com> Message-ID: <56965CFC.7020500@oracle.com> Looks reasonable to me, but I very rarely run hotspot tests. /Erik On 2016-01-13 15:04, Erik Helin wrote: > (added missing subject) > > On 2016-01-13, Erik Helin wrote: >> Hi all, >> >> this patch changes the output directory for hotspot's jtreg tests when >> run via the top-level Makefile targets such as >> `make test-hotspot-jtreg`. >> >> The current directory is >> /build//hotspot/linux-x64/testoutput >> (on an x86-64 machine running Linux). There is no need to place the >> "testoutput" directory in a directory which name is based on OS and arch, >> that is already done by the current configuration. Therefore, we can >> instead place the "testoutput" directory in >> /build//hotspot/, which is a more reasonable location >> for the output from hotspot's tests. >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8146985 >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >> >> Testing: >> - Running `make test-hotspot-jtreg` locally >> - JPRT (the patch does not affect JPRT since JPRT does not use >> ALT_OUTPUTDIR) >> >> Thanks, >> Erik From magnus.ihse.bursie at oracle.com Wed Jan 13 14:43:52 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 13 Jan 2016 15:43:52 +0100 Subject: RFR: JDK-8146995 Introduce named arguments in configure Message-ID: <569662A8.8000802@oracle.com> Similar to how we use named argument in makefiles, we should support named arguments in the configure scripts. This is possible using some m4 black magic. My long-term goal with this is to provide readable functions for handling common patterns, like parsing --with arguments and doing proper action depending on the value of the flag. Since the m4 logic is hairy, to say the least, I chose to pick a more simple function to use as test bench for getting the actual m4 underpinning to work. The essence of this change can be seen here: - FLAGS_COMPILER_CHECK_ARGUMENTS([$STACK_PROTECTOR_CFLAG], [], [STACK_PROTECTOR_CFLAG=""]) + FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$STACK_PROTECTOR_CFLAG], IF_FALSE: [STACK_PROTECTOR_CFLAG=""]) Just like in our Setup* macros in make, now it is possible to use named arguments in autoconf macros. Named arguments can come in any order. The framework will verify that only known arguments is allowed in. It is also possible to mark an argument as compulsory (by prefixing it with *). The framework will verify that all required arguments are present. Don't ask me to explain the finer points of BASIC_DEFUN_NAMED. :) m4/autoconf is non-trivial to get correct, with few debugging possibilities and sparse documentation. There's a lot of trial and error behind this final version. :-& Bug: https://bugs.openjdk.java.net/browse/JDK-8146995 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8146995-named-arguments-in-configure/webrev.01 /Magnus From staffan.larsen at oracle.com Wed Jan 13 14:59:03 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 13 Jan 2016 15:59:03 +0100 Subject: RFR: In-Reply-To: <20160113140128.GE17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> Message-ID: <876885C7-0EB8-4AC1-952C-F614888735F9@oracle.com> Looks good! (Although /build//testoutput/hotspot/ could be even better?) Thanks, /Staffan > On 13 jan. 2016, at 15:01, Erik Helin wrote: > > Hi all, > > this patch changes the output directory for hotspot's jtreg tests when > run via the top-level Makefile targets such as > `make test-hotspot-jtreg`. > > The current directory is > /build//hotspot/linux-x64/testoutput > (on an x86-64 machine running Linux). There is no need to place the > "testoutput" directory in a directory which name is based on OS and arch, > that is already done by the current configuration. Therefore, we can > instead place the "testoutput" directory in > /build//hotspot/, which is a more reasonable location > for the output from hotspot's tests. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8146985 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146985/00/webrev > > Testing: > - Running `make test-hotspot-jtreg` locally > - JPRT (the patch does not affect JPRT since JPRT does not use > ALT_OUTPUTDIR) > > Thanks, > Erik From erik.helin at oracle.com Wed Jan 13 15:11:32 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 13 Jan 2016 16:11:32 +0100 Subject: RFR: In-Reply-To: <876885C7-0EB8-4AC1-952C-F614888735F9@oracle.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <876885C7-0EB8-4AC1-952C-F614888735F9@oracle.com> Message-ID: <20160113151132.GH17653@ehelin.jrpg.bea.com> On 2016-01-13, Staffan Larsen wrote: > Looks good! Thanks! On 2016-01-13, Staffan Larsen wrote: > (Although /build//testoutput/hotspot/ could be even better?) Doesn't really matter to me, I'm fine with either hotspot/testoutput or testoutput/hotspot. Anyone else have a preference? Thanks, Erik > Thanks, > /Staffan > > > > On 13 jan. 2016, at 15:01, Erik Helin wrote: > > > > Hi all, > > > > this patch changes the output directory for hotspot's jtreg tests when > > run via the top-level Makefile targets such as > > `make test-hotspot-jtreg`. > > > > The current directory is > > /build//hotspot/linux-x64/testoutput > > (on an x86-64 machine running Linux). There is no need to place the > > "testoutput" directory in a directory which name is based on OS and arch, > > that is already done by the current configuration. Therefore, we can > > instead place the "testoutput" directory in > > /build//hotspot/, which is a more reasonable location > > for the output from hotspot's tests. > > > > Enhancement: > > https://bugs.openjdk.java.net/browse/JDK-8146985 > > > > Webrev: > > http://cr.openjdk.java.net/~ehelin/8146985/00/webrev > > > > Testing: > > - Running `make test-hotspot-jtreg` locally > > - JPRT (the patch does not affect JPRT since JPRT does not use > > ALT_OUTPUTDIR) > > > > Thanks, > > Erik > From roger.riggs at oracle.com Wed Jan 13 15:15:35 2016 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 13 Jan 2016 10:15:35 -0500 Subject: RFR: In-Reply-To: <20160113151132.GH17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <876885C7-0EB8-4AC1-952C-F614888735F9@oracle.com> <20160113151132.GH17653@ehelin.jrpg.bea.com> Message-ID: <56966A17.8050409@oracle.com> $.02, for testoutput/hotspot so that if other repos do something similar they are all under testoutput/... Roger On 1/13/16 10:11 AM, Erik Helin wrote: > On 2016-01-13, Staffan Larsen wrote: >> Looks good! > Thanks! > > On 2016-01-13, Staffan Larsen wrote: >> (Although /build//testoutput/hotspot/ could be even better?) > Doesn't really matter to me, I'm fine with either hotspot/testoutput or > testoutput/hotspot. Anyone else have a preference? > > Thanks, > Erik > >> Thanks, >> /Staffan >> >> >>> On 13 jan. 2016, at 15:01, Erik Helin wrote: >>> >>> Hi all, >>> >>> this patch changes the output directory for hotspot's jtreg tests when >>> run via the top-level Makefile targets such as >>> `make test-hotspot-jtreg`. >>> >>> The current directory is >>> /build//hotspot/linux-x64/testoutput >>> (on an x86-64 machine running Linux). There is no need to place the >>> "testoutput" directory in a directory which name is based on OS and arch, >>> that is already done by the current configuration. Therefore, we can >>> instead place the "testoutput" directory in >>> /build//hotspot/, which is a more reasonable location >>> for the output from hotspot's tests. >>> >>> Enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8146985 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >>> >>> Testing: >>> - Running `make test-hotspot-jtreg` locally >>> - JPRT (the patch does not affect JPRT since JPRT does not use >>> ALT_OUTPUTDIR) >>> >>> Thanks, >>> Erik From derek.white at oracle.com Fri Jan 8 22:07:51 2016 From: derek.white at oracle.com (Derek White) Date: Fri, 8 Jan 2016 17:07:51 -0500 Subject: Is there any valid reason that a debug or fastdebug build should define PRODUCT and not ASSERT during compiles? Message-ID: <56903337.3080802@oracle.com> [This is likely a bug, but thought I'd ask it as a question first]. I'm new to jdk builds on windows, and have spent way more time than I'd like to admit on figuring out why my fastdebug builds did not have asserts turned on. The TL;DR; answer is that anyone can build this way on Windows by simply executing this in cygwin before doing a make: > export release="Derek is having a fun day" > bash common/bin/jib.sh make -p windows-x86-debug -- images (This bug has nothing to do with jib, it's just the actual command line I used.) This results in a build with both /D "DEBUG_LEVEL=\"fastdebug\"" and /D "PRODUCT" set, because nmake.exe uppercases all environment variables as it imports them (as a convenience to the user). I'd think that there is no useful purpose to supporting such a configuration, and it's a bug to attempt it. I suggest doing an "!ifdef RELEASE" check in windows/makefiles/debug.make and windows/makefiles/fastdebug.make that either errors or unsets RELEASE before including vm.make. Any thoughts on this? Thanks! - Derek From derek.white at oracle.com Fri Jan 8 22:16:33 2016 From: derek.white at oracle.com (Derek White) Date: Fri, 8 Jan 2016 17:16:33 -0500 Subject: --with-devkit doesn't control nmake Message-ID: <56903541.6080408@oracle.com> [This is likely a bug, but thought I'd ask it as a question first]. Windows devkits contain an nmake.exe, but the configure and make scripts do not define and consistently use an NMAKE variable to make sure the devkit version is used, as many other commands do. I had assumed that my builds were using the nmake.exe from the same devkit toolchain as the compilers, etc., but in fact I was using nmake from VS2005, as provided by my company's devops department on my entitlement machine. I don't believe that actually caused problems in my builds, but it took a while to confirm it, and could easily cause a problem in the future. Bug or no bug? Thanks! - Derek From david.buck at oracle.com Wed Jan 13 11:57:16 2016 From: david.buck at oracle.com (david buck) Date: Wed, 13 Jan 2016 20:57:16 +0900 Subject: RFR(XS): 8146979: Backport of 8046471 breaks ppc64 build in jdk8u because 8072383 was badly backported before In-Reply-To: References: Message-ID: <56963B9C.2040605@oracle.com> Approved with the condition that peer code review is approved before pushing. If the review is done on a different OpenJDK alias, please send a link for that review thread to this thread before pushing. Cheers, -Buck On 2016/01/13 20:40, Volker Simonis wrote: > Hi, > > I please need an urgent review for this little patch in jdk8u-dev > which fixes a build problem on ppc64. > > Can I push this myself directly to > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot ? > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8146979/ > https://bugs.openjdk.java.net/browse/JDK-8146979 > > Recently the change "8046471: Use OPENJDK_TARGET_CPU_ARCH instead of > legacy value for hotspot ARCH" was backporeted to jdk8u. It changes > the ARCH value which is passed from the top-level configure to the > hotspot make via the hotspot-spec.gmk file. For the ppc64 architecture > this changes the reported value for ARCH from 'ppc64' to 'ppc'. > > In jdk9 this is no problem, because the hotspot makefiles correctly > handle this value. Unfortunately in jdk8u this is not the case, > because the change "8072383: resolve conflicts between open and closed > ports" hasn't been correctly downported from jdk9 to jdk8u before. > > In jdk9 it contains the following lines: > > - SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc > ppc64 aarch64 zero,$(ARCH))) > + SRCARCH ?= $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 ppc ppc64 > aarch64 zero,$(ARCH))) > > ARCH/ppc64 = ppc > ARCH/ppc = ppc > - ARCH/arm = arm > ARCH/aarch64= aarch64 > > but in the downport this was for whatever reason changed to: > > - SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc > ppc64 zero,$(ARCH))) > + SRCARCH ?= $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 ppc64 > zero,$(ARCH))) > > ARCH/ppc64 = ppc > - ARCH/ppc = ppc > - ARCH/arm = arm > ARCH/zero = zero > > Notice how in jdk8u 'ppc' was removed from SRCARCH and how the line > 'ARCH/ppc = ppc' was completely deleted in jdk8u. > > We need to fix these two line in jdk8u in order to make the build work > again on ppc64. > > Regards, > Volker > From magnus.ihse.bursie at oracle.com Wed Jan 13 16:26:18 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 13 Jan 2016 17:26:18 +0100 Subject: RFR: In-Reply-To: <56966A17.8050409@oracle.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <876885C7-0EB8-4AC1-952C-F614888735F9@oracle.com> <20160113151132.GH17653@ehelin.jrpg.bea.com> <56966A17.8050409@oracle.com> Message-ID: <9A4823B6-F6D0-4C58-BD14-C3E7745AB7D0@oracle.com> I agree. It seems better to collect all test output in a central place. /Magnus > 13 jan. 2016 kl. 16:15 skrev Roger Riggs : > > $.02, for testoutput/hotspot > > so that if other repos do something similar they are all under testoutput/... > > Roger > > >> On 1/13/16 10:11 AM, Erik Helin wrote: >>> On 2016-01-13, Staffan Larsen wrote: >>> Looks good! >> Thanks! >> >>> On 2016-01-13, Staffan Larsen wrote: >>> (Although /build//testoutput/hotspot/ could be even better?) >> Doesn't really matter to me, I'm fine with either hotspot/testoutput or >> testoutput/hotspot. Anyone else have a preference? >> >> Thanks, >> Erik >> >>> Thanks, >>> /Staffan >>> >>> >>>> On 13 jan. 2016, at 15:01, Erik Helin wrote: >>>> >>>> Hi all, >>>> >>>> this patch changes the output directory for hotspot's jtreg tests when >>>> run via the top-level Makefile targets such as >>>> `make test-hotspot-jtreg`. >>>> >>>> The current directory is >>>> /build//hotspot/linux-x64/testoutput >>>> (on an x86-64 machine running Linux). There is no need to place the >>>> "testoutput" directory in a directory which name is based on OS and arch, >>>> that is already done by the current configuration. Therefore, we can >>>> instead place the "testoutput" directory in >>>> /build//hotspot/, which is a more reasonable location >>>> for the output from hotspot's tests. >>>> >>>> Enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8146985 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >>>> >>>> Testing: >>>> - Running `make test-hotspot-jtreg` locally >>>> - JPRT (the patch does not affect JPRT since JPRT does not use >>>> ALT_OUTPUTDIR) >>>> >>>> Thanks, >>>> Erik > From magnus.ihse.bursie at oracle.com Wed Jan 13 16:35:57 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 13 Jan 2016 17:35:57 +0100 Subject: RFR: JDK-8146403: Windows build can be faster In-Reply-To: <569654D9.2090904@oracle.com> References: <568BA1D1.2060104@oracle.com> <5696398F.8040706@oracle.com> <569654D9.2090904@oracle.com> Message-ID: <65C7CCBB-E4D2-4869-A4EB-35499BB36729@oracle.com> Looks good to me. /Magnus > 13 jan. 2016 kl. 14:44 skrev Erik Joelsson : > > Hello, > > New webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.02/ > > Fixed the below comments. Also adjusted some more gensrc log output to make it more uniform, even if it doesn't exactly address Windows performance. > > I also fixed a bug in the bootstrap make logic. The module-deps.gmk wasn't correctly generated in all cases. Typically when building more than one conf at a time or when doing a compare build. I added explicit calls to GenerateModuleDeps.gmk to fix this. > > /Erik > >> On 2016-01-13 12:48, Magnus Ihse Bursie wrote: >> Hi, >> >> In InitSupport.gmk, please restore the comment: >> # Only do this if make has not been restarted, and if we do not force it. >> >> In jdk/make/gensrc/GensrcExceptions.gmk: >> The old construct resulted in the output "Generating exceptions classes" (but a bit irregularly), could you please re-add it as a LogInfo? >> >> In make/CompileTools.gmk, the copyright header says 2014, which is at least one year too early. :-) (In fact, all modified files should really get bumped to 2016). >> >> Apart from this, it looks good to me. >> >> /Magnus >> >>> On 2016-01-05 11:58, Erik Joelsson wrote: >>> Hello, >>> >>> During the hotspot makefile conversion, we have been reminded of inefficiencies when running make in Cygwin. We still have a pretty severe performance regression in the new hotspot build compared to the old on Windows in certain situations, my laptop being one such situation. A recent comparison there between just the old and new hotspot build: >>> >>> release new 00:04:30 >>> release old 00:03:10 >>> fastdebug new 00:04:59 >>> fastdebug old 00:03:37 >>> >>> Much of the extra time is spent spawning various shell processes for book keeping, like saving failure logs, creating header dependency files etc. >>> >>> It also takes a very long time to do a "do nothing" rebuild when nothing has changed. On my laptop, repeating "make jimages" often takes as long as 40 seconds to figure out that nothing needs to be rebuilt. In this case there are several culprits. >>> >>> I have been working on improvements in these areas to reduce the overhead. The "do nothing" rebuild of jimages is down to around 25 seconds. A full images build is around 1-2 minutes faster from 24 to 22 minutes, but fluctuates quite a bit. The new hotspot build is also improved: >>> >>> release: 3:44 >>> fastdebug: 4:02 >>> >>> Here is a list of the kinds of changes I've made: >>> >>> * Rewrote logger.sh to use a different construct. It drastically reduces the number of bash processes being spawned. Basically you can pipe like this: "> >(tee logfile) 2> >(tee logfile >&2)". I also managed to reduce the extra sed/grep commands needed for the header dependencies even more. A side effect of this is that the log files for each native compilation unit are always saved instead of being deleted on successful compilation. I see no issue with this. >>> >>> * Changed all recipes that contain echo for logging to instead use new LogInfo macro, which in turn calls $(info ) if appropriate. >>> >>> * Changed all recipes that contain mkdir to instead use MakeDir macro, which only executes mkdir if the directory doesn't exist. >>> >>> * In HotspotWrapper.gmk there is an optimization to avoid calling the hotspot makefiles at all if nothing has changed. This runs a find over the whole hotspot repository. I reduced this to only run over src and make sub dirs to avoid the pretty large test dir (since test/closed has grown quite a bit). >>> >>> * Split Tools.gmk into CompileTools.gmk and Tools.gmk, to avoid having the buildtools compilation being reevaluated by all makefiles needing the tools definitions. >>> >>> * Split Modules.gmk to avoid having the module deps generation being reevaluated multiple times. Made the new GenerateModuleDeps.gmk an explicit call from Init.gmk. >>> >>> Since these improvements affect much more than just the new hotspot build, I intend to push this to JDK 9 directly. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146403 >>> Webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.01/ >>> >>> /Erik >> > From erik.joelsson at oracle.com Wed Jan 13 18:51:16 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Jan 2016 19:51:16 +0100 Subject: --with-devkit doesn't control nmake In-Reply-To: <56903541.6080408@oracle.com> References: <56903541.6080408@oracle.com> Message-ID: <56969CA4.506@oracle.com> For your build to pick up nmake from some other VS installation means you must have that VS installation in your path. Normally, only the devkit bin dirs will be in the path if you start with a clean environment. We have simply not encountered that before, but it is definitely a bug. However, the hotspot build-infra project is currently rewriting the hotspot makefiles (see build-infra/jdk9 forest if you are interested) and we are getting rid of nmake. This project will go into JDK 9 in hopefully not too long a time. Unless this is causing actual trouble now, we in the build group will be reluctant to spend time on fixing the issue. We would of course welcome contributions from others if someone is willing to do the work. /Erik On 2016-01-08 23:16, Derek White wrote: > [This is likely a bug, but thought I'd ask it as a question first]. > > Windows devkits contain an nmake.exe, but the configure and make > scripts do not define and consistently use an NMAKE variable to make > sure the devkit version is used, as many other commands do. > > I had assumed that my builds were using the nmake.exe from the same > devkit toolchain as the compilers, etc., but in fact I was using nmake > from VS2005, as provided by my company's devops department on my > entitlement machine. > > I don't believe that actually caused problems in my builds, but it > took a while to confirm it, and could easily cause a problem in the > future. > > Bug or no bug? Thanks! > > - Derek From mikael.vidstedt at oracle.com Wed Jan 13 18:54:18 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 13 Jan 2016 10:54:18 -0800 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tets to build/conf/hotspot/testoutput In-Reply-To: <20160113140405.GF17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160113140405.GF17653@ehelin.jrpg.bea.com> Message-ID: <56969D5A.1020203@oracle.com> The logic in this file (hotspot/test/Makefile) is very similar to that of jdk/test/Makefile, as a matter of fact some of it has been copy pasted. It would be nice if the output dir paths would be set up the same way in both cases, to avoid confusion and all of that. It would be even better to share the logic all together to avoid duplication, but that's a separate issue. Cheers, Mikael On 2016-01-13 06:04, Erik Helin wrote: > (added missing subject) > > On 2016-01-13, Erik Helin wrote: >> Hi all, >> >> this patch changes the output directory for hotspot's jtreg tests when >> run via the top-level Makefile targets such as >> `make test-hotspot-jtreg`. >> >> The current directory is >> /build//hotspot/linux-x64/testoutput >> (on an x86-64 machine running Linux). There is no need to place the >> "testoutput" directory in a directory which name is based on OS and arch, >> that is already done by the current configuration. Therefore, we can >> instead place the "testoutput" directory in >> /build//hotspot/, which is a more reasonable location >> for the output from hotspot's tests. >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8146985 >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >> >> Testing: >> - Running `make test-hotspot-jtreg` locally >> - JPRT (the patch does not affect JPRT since JPRT does not use >> ALT_OUTPUTDIR) >> >> Thanks, >> Erik From mikael.vidstedt at oracle.com Wed Jan 13 18:54:59 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 13 Jan 2016 10:54:59 -0800 Subject: RFR: 8146871: Make the clean target silent in hotspot/test/Makefile In-Reply-To: <20160113124707.GD17653@ehelin.jrpg.bea.com> References: <20160113124707.GD17653@ehelin.jrpg.bea.com> Message-ID: <56969D83.1050906@oracle.com> Loos good, and is already true for the corresponding logic in jdk/test/Makefile. Cheers, Mikael On 2016-01-13 04:47, Erik Helin wrote: > Hi all, > > this very small patches silences the 'clean' target in > hotspot/test/Makefile (the 'prep' target is already silent). > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8146871 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146871/00/webrev/ > > Testing: > - Buiding locally and verified that the commands are no longer listed > - JPRT > > Thanks, > Erik From erik.joelsson at oracle.com Wed Jan 13 19:02:27 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Jan 2016 20:02:27 +0100 Subject: RFR: 8146871: Make the clean target silent in hotspot/test/Makefile In-Reply-To: <56969D83.1050906@oracle.com> References: <20160113124707.GD17653@ehelin.jrpg.bea.com> <56969D83.1050906@oracle.com> Message-ID: <56969F43.6070206@oracle.com> If it's the same in jdk/test/Makefile, then I have no objections. Keep it consistent. Ok from me. /Erik On 2016-01-13 19:54, Mikael Vidstedt wrote: > > Loos good, and is already true for the corresponding logic in > jdk/test/Makefile. > > Cheers, > Mikael > > On 2016-01-13 04:47, Erik Helin wrote: >> Hi all, >> >> this very small patches silences the 'clean' target in >> hotspot/test/Makefile (the 'prep' target is already silent). >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8146871 >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8146871/00/webrev/ >> >> Testing: >> - Buiding locally and verified that the commands are no longer listed >> - JPRT >> >> Thanks, >> Erik > From erik.joelsson at oracle.com Wed Jan 13 19:18:35 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Jan 2016 20:18:35 +0100 Subject: RFR: JDK-8146995 Introduce named arguments in configure In-Reply-To: <569662A8.8000802@oracle.com> References: <569662A8.8000802@oracle.com> Message-ID: <5696A30B.2030107@oracle.com> The implementation of the m4 black magic macro certainly looks scary. I was able to understand the first conditional block. I did apply and try the patch and verified that -stack-protector was added to cflags when setting slowdebug. The readability of the macro calls are definitely much more understandable. I like it. Looks good. /Erik On 2016-01-13 15:43, Magnus Ihse Bursie wrote: > Similar to how we use named argument in makefiles, we should support > named arguments in the configure scripts. This is possible using some > m4 black magic. > > My long-term goal with this is to provide readable functions for > handling common patterns, like parsing --with arguments and doing > proper action depending on the value of the flag. > > Since the m4 logic is hairy, to say the least, I chose to pick a more > simple function to use as test bench for getting the actual m4 > underpinning to work. > > The essence of this change can be seen here: > > - FLAGS_COMPILER_CHECK_ARGUMENTS([$STACK_PROTECTOR_CFLAG], [], > [STACK_PROTECTOR_CFLAG=""]) > + FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$STACK_PROTECTOR_CFLAG], > IF_FALSE: [STACK_PROTECTOR_CFLAG=""]) > > > Just like in our Setup* macros in make, now it is possible to use > named arguments in autoconf macros. Named arguments can come in any > order. The framework will verify that only known arguments is allowed > in. It is also possible to mark an argument as compulsory (by > prefixing it with *). The framework will verify that all required > arguments are present. > > Don't ask me to explain the finer points of BASIC_DEFUN_NAMED. :) > m4/autoconf is non-trivial to get correct, with few debugging > possibilities and sparse documentation. There's a lot of trial and > error behind this final version. :-& > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146995 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8146995-named-arguments-in-configure/webrev.01 > > /Magnus > From staffan.larsen at oracle.com Wed Jan 13 19:36:18 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 13 Jan 2016 20:36:18 +0100 Subject: RFR: In-Reply-To: <20160113151132.GH17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <876885C7-0EB8-4AC1-952C-F614888735F9@oracle.com> <20160113151132.GH17653@ehelin.jrpg.bea.com> Message-ID: <7B8310A1-5290-497C-B9AD-B4D3B8DB69EF@oracle.com> > On 13 jan. 2016, at 16:11, Erik Helin wrote: > > On 2016-01-13, Staffan Larsen wrote: >> Looks good! > > Thanks! > > On 2016-01-13, Staffan Larsen wrote: >> (Although /build//testoutput/hotspot/ could be even better?) > > Doesn't really matter to me, I'm fine with either hotspot/testoutput or > testoutput/hotspot. Anyone else have a preference? I don?t have a strong preference - feel free to commit the patch as is. /Staffan > > Thanks, > Erik > >> Thanks, >> /Staffan >> >> >>> On 13 jan. 2016, at 15:01, Erik Helin wrote: >>> >>> Hi all, >>> >>> this patch changes the output directory for hotspot's jtreg tests when >>> run via the top-level Makefile targets such as >>> `make test-hotspot-jtreg`. >>> >>> The current directory is >>> /build//hotspot/linux-x64/testoutput >>> (on an x86-64 machine running Linux). There is no need to place the >>> "testoutput" directory in a directory which name is based on OS and arch, >>> that is already done by the current configuration. Therefore, we can >>> instead place the "testoutput" directory in >>> /build//hotspot/, which is a more reasonable location >>> for the output from hotspot's tests. >>> >>> Enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8146985 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >>> >>> Testing: >>> - Running `make test-hotspot-jtreg` locally >>> - JPRT (the patch does not affect JPRT since JPRT does not use >>> ALT_OUTPUTDIR) >>> >>> Thanks, >>> Erik >> From erik.joelsson at oracle.com Wed Jan 13 19:50:47 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Jan 2016 20:50:47 +0100 Subject: RFR: JDK-8146995 Introduce named arguments in configure In-Reply-To: <569662A8.8000802@oracle.com> References: <569662A8.8000802@oracle.com> Message-ID: <5696AA97.5010106@oracle.com> Forgot to include this in the last mail. Typo in comment. basics.m4 27: like like No need to redo webrev. /Erik On 2016-01-13 15:43, Magnus Ihse Bursie wrote: > Similar to how we use named argument in makefiles, we should support > named arguments in the configure scripts. This is possible using some > m4 black magic. > > My long-term goal with this is to provide readable functions for > handling common patterns, like parsing --with arguments and doing > proper action depending on the value of the flag. > > Since the m4 logic is hairy, to say the least, I chose to pick a more > simple function to use as test bench for getting the actual m4 > underpinning to work. > > The essence of this change can be seen here: > > - FLAGS_COMPILER_CHECK_ARGUMENTS([$STACK_PROTECTOR_CFLAG], [], > [STACK_PROTECTOR_CFLAG=""]) > + FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$STACK_PROTECTOR_CFLAG], > IF_FALSE: [STACK_PROTECTOR_CFLAG=""]) > > > Just like in our Setup* macros in make, now it is possible to use > named arguments in autoconf macros. Named arguments can come in any > order. The framework will verify that only known arguments is allowed > in. It is also possible to mark an argument as compulsory (by > prefixing it with *). The framework will verify that all required > arguments are present. > > Don't ask me to explain the finer points of BASIC_DEFUN_NAMED. :) > m4/autoconf is non-trivial to get correct, with few debugging > possibilities and sparse documentation. There's a lot of trial and > error behind this final version. :-& > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146995 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8146995-named-arguments-in-configure/webrev.01 > > /Magnus > From swpalmer at gmail.com Wed Jan 13 21:39:20 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 13 Jan 2016 16:39:20 -0500 Subject: Configure(still?) broken on OS X Message-ID: There was a recent thread about JDK-8145206: Configure broken on Macosx I just attempted to bulid jdk9 on OS X 10.11.2 and configure failed with: configure: error: Could not find freetype! /Users/me/dev/openjdk9.common/autoconf/generated-configure.sh: line 82: 5: Bad file descriptor Checking README-builds.html I see that Freetype is listed as something that is needed for Linux and Solaris, but not Mac OS X. What is broken, configure or the System Setup instructions? Thanks, Scott From david.holmes at oracle.com Thu Jan 14 04:15:56 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Jan 2016 14:15:56 +1000 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tets to build/conf/hotspot/testoutput In-Reply-To: <56969D5A.1020203@oracle.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160113140405.GF17653@ehelin.jrpg.bea.com> <56969D5A.1020203@oracle.com> Message-ID: <569720FC.7080409@oracle.com> Sorry I don't understand the change. AFAICS ALT_OUTPUTDIR could be anything - no guarantee that it already contains the "CONF" directory. Any why only change one path: ifdef ALT_OUTPUTDIR ! ABS_BUILD_ROOT = $(ALT_OUTPUTDIR)/hotspot else ABS_BUILD_ROOT = $(TEST_ROOT)/../build/$(PLATFORM)-$(ARCH) ?? When do we take each path? David ----- On 14/01/2016 4:54 AM, Mikael Vidstedt wrote: > > The logic in this file (hotspot/test/Makefile) is very similar to that > of jdk/test/Makefile, as a matter of fact some of it has been copy > pasted. It would be nice if the output dir paths would be set up the > same way in both cases, to avoid confusion and all of that. > > It would be even better to share the logic all together to avoid > duplication, but that's a separate issue. > > Cheers, > Mikael > > On 2016-01-13 06:04, Erik Helin wrote: >> (added missing subject) >> >> On 2016-01-13, Erik Helin wrote: >>> Hi all, >>> >>> this patch changes the output directory for hotspot's jtreg tests when >>> run via the top-level Makefile targets such as >>> `make test-hotspot-jtreg`. >>> >>> The current directory is >>> /build//hotspot/linux-x64/testoutput >>> (on an x86-64 machine running Linux). There is no need to place the >>> "testoutput" directory in a directory which name is based on OS and >>> arch, >>> that is already done by the current configuration. Therefore, we can >>> instead place the "testoutput" directory in >>> /build//hotspot/, which is a more reasonable location >>> for the output from hotspot's tests. >>> >>> Enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8146985 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >>> >>> Testing: >>> - Running `make test-hotspot-jtreg` locally >>> - JPRT (the patch does not affect JPRT since JPRT does not use >>> ALT_OUTPUTDIR) >>> >>> Thanks, >>> Erik > From thomas.stuefe at gmail.com Thu Jan 14 07:29:50 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 14 Jan 2016 08:29:50 +0100 Subject: javac server: No port file values materialized. on AIX Message-ID: Hi all, on AIX, I keep getting Server log: ------- Server log start ------- ------- Server log end --------- [CLIENT] Exception caught: java.io.IOException: No port file values materialized. Giving up after 5375 ms java.io.IOException: No port file values materialized. Giving up after 5375 ms at com.sun.tools.sjavac.server.PortFile.waitForValidValues(PortFile.java:242) at com.sun.tools.sjavac.client.SjavacClient.fork(SjavacClient.java:262) at com.sun.tools.sjavac.client.SjavacClient.makeSureServerIsRunning(SjavacClient.java:216) at com.sun.tools.sjavac.client.SjavacClient.tryConnect(SjavacClient.java:173) at com.sun.tools.sjavac.client.SjavacClient.compile(SjavacClient.java:126) at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:84) at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:47) at com.sun.tools.sjavac.Main.go(Main.java:56) at com.sun.tools.sjavac.Main.main(Main.java:46) javac server issues when building. I build hs-rt, and I manually applied the patch from https://bugs.openjdk.java.net/browse/JDK-8145944 which fixes the windows-delayed-delete-issue, but that (obviously) does not help on AIX. My current workaround is --disable-javac-server. But I would prefer running with javac server, my AIX build machine is slow enough as it is :) Any suggestions? Thanks! Kind Regards, Thomas From erik.joelsson at oracle.com Thu Jan 14 08:01:42 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Jan 2016 09:01:42 +0100 Subject: Configure(still?) broken on OS X In-Reply-To: References: Message-ID: <569755E6.7060208@oracle.com> I believe freetype is needed on Macosx so if that is missing in README-builds.html, that's a bug. I'm not a regular Macosx user so I might remember this wrong, but you can get freetype from different sources. One is to install XQuartz. Another is to get it from homebrew. There was some issue with Macosx 10.11 and the path to freetype in XQuartz but I think that should be fixed now. /Erik On 2016-01-13 22:39, Scott Palmer wrote: > There was a recent thread about JDK-8145206: Configure broken on Macosx > > I just attempted to bulid jdk9 on OS X 10.11.2 and configure failed with: > > configure: error: Could not find freetype! > /Users/me/dev/openjdk9.common/autoconf/generated-configure.sh: line 82: 5: > Bad file descriptor > > > Checking README-builds.html I see that Freetype is listed as something that > is needed for Linux and Solaris, but not Mac OS X. > > What is broken, configure or the System Setup instructions? > > Thanks, > > Scott From erik.joelsson at oracle.com Thu Jan 14 08:06:56 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Jan 2016 09:06:56 +0100 Subject: javac server: No port file values materialized. on AIX In-Reply-To: References: Message-ID: <56975720.2010606@oracle.com> There is a bug for that as we see the same thing on Solaris from time to time, as I see you know. Andreas, who is the main engineer working on sjavac, is currently on vacation. We don't currently know the cause of this issue. Any help would be appreciated. /Erik On 2016-01-14 08:29, Thomas St?fe wrote: > Hi all, > > on AIX, I keep getting > > Server log: > ------- Server log start ------- > ------- Server log end --------- > [CLIENT] Exception caught: java.io.IOException: No port file values > materialized. Giving up after 5375 ms > java.io.IOException: No port file values materialized. Giving up after 5375 > ms > at > com.sun.tools.sjavac.server.PortFile.waitForValidValues(PortFile.java:242) > at > com.sun.tools.sjavac.client.SjavacClient.fork(SjavacClient.java:262) > at > com.sun.tools.sjavac.client.SjavacClient.makeSureServerIsRunning(SjavacClient.java:216) > at > com.sun.tools.sjavac.client.SjavacClient.tryConnect(SjavacClient.java:173) > at > com.sun.tools.sjavac.client.SjavacClient.compile(SjavacClient.java:126) > at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:84) > at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:47) > at com.sun.tools.sjavac.Main.go(Main.java:56) > at com.sun.tools.sjavac.Main.main(Main.java:46) > > javac server issues when building. > > I build hs-rt, and I manually applied the patch from > > https://bugs.openjdk.java.net/browse/JDK-8145944 > > which fixes the windows-delayed-delete-issue, but that (obviously) does not > help on AIX. > > My current workaround is --disable-javac-server. But I would prefer running > with javac server, my AIX build machine is slow enough as it is :) > > Any suggestions? > > Thanks! Kind Regards, Thomas From erik.joelsson at oracle.com Thu Jan 14 10:43:57 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Jan 2016 11:43:57 +0100 Subject: RFR: JDK-8146403: Windows build can be faster In-Reply-To: <569654D9.2090904@oracle.com> References: <568BA1D1.2060104@oracle.com> <5696398F.8040706@oracle.com> <569654D9.2090904@oracle.com> Message-ID: <56977BED.3040103@oracle.com> Hello, Thinking more about the new bootstrap logic, I feel that I don't like the solution. Here is a new patch where I only changed that part. I reverted to using the -include mechanism to trigger generation of module-deps.gmk, but still in a separate makefile that is only included by Main.gmk. Webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.03/ /Erik On 2016-01-13 14:44, Erik Joelsson wrote: > Hello, > > New webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.02/ > > Fixed the below comments. Also adjusted some more gensrc log output to > make it more uniform, even if it doesn't exactly address Windows > performance. > > I also fixed a bug in the bootstrap make logic. The module-deps.gmk > wasn't correctly generated in all cases. Typically when building more > than one conf at a time or when doing a compare build. I added > explicit calls to GenerateModuleDeps.gmk to fix this. > > /Erik > > On 2016-01-13 12:48, Magnus Ihse Bursie wrote: >> Hi, >> >> In InitSupport.gmk, please restore the comment: >> # Only do this if make has not been restarted, and if we do not >> force it. >> >> In jdk/make/gensrc/GensrcExceptions.gmk: >> The old construct resulted in the output "Generating exceptions >> classes" (but a bit irregularly), could you please re-add it as a >> LogInfo? >> >> In make/CompileTools.gmk, the copyright header says 2014, which is at >> least one year too early. :-) (In fact, all modified files should >> really get bumped to 2016). >> >> Apart from this, it looks good to me. >> >> /Magnus >> >> On 2016-01-05 11:58, Erik Joelsson wrote: >>> Hello, >>> >>> During the hotspot makefile conversion, we have been reminded of >>> inefficiencies when running make in Cygwin. We still have a pretty >>> severe performance regression in the new hotspot build compared to >>> the old on Windows in certain situations, my laptop being one such >>> situation. A recent comparison there between just the old and new >>> hotspot build: >>> >>> release new 00:04:30 >>> release old 00:03:10 >>> fastdebug new 00:04:59 >>> fastdebug old 00:03:37 >>> >>> Much of the extra time is spent spawning various shell processes for >>> book keeping, like saving failure logs, creating header dependency >>> files etc. >>> >>> It also takes a very long time to do a "do nothing" rebuild when >>> nothing has changed. On my laptop, repeating "make jimages" often >>> takes as long as 40 seconds to figure out that nothing needs to be >>> rebuilt. In this case there are several culprits. >>> >>> I have been working on improvements in these areas to reduce the >>> overhead. The "do nothing" rebuild of jimages is down to around 25 >>> seconds. A full images build is around 1-2 minutes faster from 24 to >>> 22 minutes, but fluctuates quite a bit. The new hotspot build is >>> also improved: >>> >>> release: 3:44 >>> fastdebug: 4:02 >>> >>> Here is a list of the kinds of changes I've made: >>> >>> * Rewrote logger.sh to use a different construct. It drastically >>> reduces the number of bash processes being spawned. Basically you >>> can pipe like this: "> >(tee logfile) 2> >(tee logfile >&2)". I also >>> managed to reduce the extra sed/grep commands needed for the header >>> dependencies even more. A side effect of this is that the log files >>> for each native compilation unit are always saved instead of being >>> deleted on successful compilation. I see no issue with this. >>> >>> * Changed all recipes that contain echo for logging to instead use >>> new LogInfo macro, which in turn calls $(info ) if appropriate. >>> >>> * Changed all recipes that contain mkdir to instead use MakeDir >>> macro, which only executes mkdir if the directory doesn't exist. >>> >>> * In HotspotWrapper.gmk there is an optimization to avoid calling >>> the hotspot makefiles at all if nothing has changed. This runs a >>> find over the whole hotspot repository. I reduced this to only run >>> over src and make sub dirs to avoid the pretty large test dir (since >>> test/closed has grown quite a bit). >>> >>> * Split Tools.gmk into CompileTools.gmk and Tools.gmk, to avoid >>> having the buildtools compilation being reevaluated by all makefiles >>> needing the tools definitions. >>> >>> * Split Modules.gmk to avoid having the module deps generation being >>> reevaluated multiple times. Made the new GenerateModuleDeps.gmk an >>> explicit call from Init.gmk. >>> >>> Since these improvements affect much more than just the new hotspot >>> build, I intend to push this to JDK 9 directly. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146403 >>> Webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.01/ >>> >>> /Erik >> > From magnus.ihse.bursie at oracle.com Thu Jan 14 10:53:33 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Jan 2016 11:53:33 +0100 Subject: RFR: JDK-8146403: Windows build can be faster In-Reply-To: <56977BED.3040103@oracle.com> References: <568BA1D1.2060104@oracle.com> <5696398F.8040706@oracle.com> <569654D9.2090904@oracle.com> <56977BED.3040103@oracle.com> Message-ID: <56977E2D.70901@oracle.com> On 2016-01-14 11:43, Erik Joelsson wrote: > Hello, > > Thinking more about the new bootstrap logic, I feel that I don't like > the solution. Here is a new patch where I only changed that part. I > reverted to using the -include mechanism to trigger generation of > module-deps.gmk, but still in a separate makefile that is only > included by Main.gmk. > > Webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.03/ It looks like this version is just like the original, but you have moved some code from Modules.gmk to GenerateModuleDeps.gmk, but since both of them is included in Main.gmk, there will be no functional changes, just a matter of code cleanup. Or am I missing something? I'm not saying it's bad, I just understand how and if this resolves what you set out to solve in your first version. /Magnus > > /Erik > > On 2016-01-13 14:44, Erik Joelsson wrote: >> Hello, >> >> New webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.02/ >> >> Fixed the below comments. Also adjusted some more gensrc log output >> to make it more uniform, even if it doesn't exactly address Windows >> performance. >> >> I also fixed a bug in the bootstrap make logic. The module-deps.gmk >> wasn't correctly generated in all cases. Typically when building more >> than one conf at a time or when doing a compare build. I added >> explicit calls to GenerateModuleDeps.gmk to fix this. >> >> /Erik >> >> On 2016-01-13 12:48, Magnus Ihse Bursie wrote: >>> Hi, >>> >>> In InitSupport.gmk, please restore the comment: >>> # Only do this if make has not been restarted, and if we do not >>> force it. >>> >>> In jdk/make/gensrc/GensrcExceptions.gmk: >>> The old construct resulted in the output "Generating exceptions >>> classes" (but a bit irregularly), could you please re-add it as a >>> LogInfo? >>> >>> In make/CompileTools.gmk, the copyright header says 2014, which is >>> at least one year too early. :-) (In fact, all modified files should >>> really get bumped to 2016). >>> >>> Apart from this, it looks good to me. >>> >>> /Magnus >>> >>> On 2016-01-05 11:58, Erik Joelsson wrote: >>>> Hello, >>>> >>>> During the hotspot makefile conversion, we have been reminded of >>>> inefficiencies when running make in Cygwin. We still have a pretty >>>> severe performance regression in the new hotspot build compared to >>>> the old on Windows in certain situations, my laptop being one such >>>> situation. A recent comparison there between just the old and new >>>> hotspot build: >>>> >>>> release new 00:04:30 >>>> release old 00:03:10 >>>> fastdebug new 00:04:59 >>>> fastdebug old 00:03:37 >>>> >>>> Much of the extra time is spent spawning various shell processes >>>> for book keeping, like saving failure logs, creating header >>>> dependency files etc. >>>> >>>> It also takes a very long time to do a "do nothing" rebuild when >>>> nothing has changed. On my laptop, repeating "make jimages" often >>>> takes as long as 40 seconds to figure out that nothing needs to be >>>> rebuilt. In this case there are several culprits. >>>> >>>> I have been working on improvements in these areas to reduce the >>>> overhead. The "do nothing" rebuild of jimages is down to around 25 >>>> seconds. A full images build is around 1-2 minutes faster from 24 >>>> to 22 minutes, but fluctuates quite a bit. The new hotspot build is >>>> also improved: >>>> >>>> release: 3:44 >>>> fastdebug: 4:02 >>>> >>>> Here is a list of the kinds of changes I've made: >>>> >>>> * Rewrote logger.sh to use a different construct. It drastically >>>> reduces the number of bash processes being spawned. Basically you >>>> can pipe like this: "> >(tee logfile) 2> >(tee logfile >&2)". I >>>> also managed to reduce the extra sed/grep commands needed for the >>>> header dependencies even more. A side effect of this is that the >>>> log files for each native compilation unit are always saved instead >>>> of being deleted on successful compilation. I see no issue with this. >>>> >>>> * Changed all recipes that contain echo for logging to instead use >>>> new LogInfo macro, which in turn calls $(info ) if appropriate. >>>> >>>> * Changed all recipes that contain mkdir to instead use MakeDir >>>> macro, which only executes mkdir if the directory doesn't exist. >>>> >>>> * In HotspotWrapper.gmk there is an optimization to avoid calling >>>> the hotspot makefiles at all if nothing has changed. This runs a >>>> find over the whole hotspot repository. I reduced this to only run >>>> over src and make sub dirs to avoid the pretty large test dir >>>> (since test/closed has grown quite a bit). >>>> >>>> * Split Tools.gmk into CompileTools.gmk and Tools.gmk, to avoid >>>> having the buildtools compilation being reevaluated by all >>>> makefiles needing the tools definitions. >>>> >>>> * Split Modules.gmk to avoid having the module deps generation >>>> being reevaluated multiple times. Made the new >>>> GenerateModuleDeps.gmk an explicit call from Init.gmk. >>>> >>>> Since these improvements affect much more than just the new hotspot >>>> build, I intend to push this to JDK 9 directly. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146403 >>>> Webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.01/ >>>> >>>> /Erik >>> >> > From erik.joelsson at oracle.com Thu Jan 14 11:01:06 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Jan 2016 12:01:06 +0100 Subject: RFR: JDK-8146403: Windows build can be faster In-Reply-To: <56977E2D.70901@oracle.com> References: <568BA1D1.2060104@oracle.com> <5696398F.8040706@oracle.com> <569654D9.2090904@oracle.com> <56977BED.3040103@oracle.com> <56977E2D.70901@oracle.com> Message-ID: <56977FF2.7050004@oracle.com> On 2016-01-14 11:53, Magnus Ihse Bursie wrote: > On 2016-01-14 11:43, Erik Joelsson wrote: >> Hello, >> >> Thinking more about the new bootstrap logic, I feel that I don't like >> the solution. Here is a new patch where I only changed that part. I >> reverted to using the -include mechanism to trigger generation of >> module-deps.gmk, but still in a separate makefile that is only >> included by Main.gmk. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.03/ > > It looks like this version is just like the original, but you have > moved some code from Modules.gmk to GenerateModuleDeps.gmk, but since > both of them is included in Main.gmk, there will be no functional > changes, just a matter of code cleanup. Or am I missing something? > > I'm not saying it's bad, I just understand how and if this resolves > what you set out to solve in your first version. > Modules.gmk is included in many places. Each such instance would have to evaluate if module-deps.gmk needed to be recreated or not, and in turn run a find over the source files for the generator tool. This is now only done in Main.gmk. /Erik > /Magnus > >> >> /Erik >> >> On 2016-01-13 14:44, Erik Joelsson wrote: >>> Hello, >>> >>> New webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.02/ >>> >>> Fixed the below comments. Also adjusted some more gensrc log output >>> to make it more uniform, even if it doesn't exactly address Windows >>> performance. >>> >>> I also fixed a bug in the bootstrap make logic. The module-deps.gmk >>> wasn't correctly generated in all cases. Typically when building >>> more than one conf at a time or when doing a compare build. I added >>> explicit calls to GenerateModuleDeps.gmk to fix this. >>> >>> /Erik >>> >>> On 2016-01-13 12:48, Magnus Ihse Bursie wrote: >>>> Hi, >>>> >>>> In InitSupport.gmk, please restore the comment: >>>> # Only do this if make has not been restarted, and if we do not >>>> force it. >>>> >>>> In jdk/make/gensrc/GensrcExceptions.gmk: >>>> The old construct resulted in the output "Generating exceptions >>>> classes" (but a bit irregularly), could you please re-add it as a >>>> LogInfo? >>>> >>>> In make/CompileTools.gmk, the copyright header says 2014, which is >>>> at least one year too early. :-) (In fact, all modified files >>>> should really get bumped to 2016). >>>> >>>> Apart from this, it looks good to me. >>>> >>>> /Magnus >>>> >>>> On 2016-01-05 11:58, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> During the hotspot makefile conversion, we have been reminded of >>>>> inefficiencies when running make in Cygwin. We still have a pretty >>>>> severe performance regression in the new hotspot build compared to >>>>> the old on Windows in certain situations, my laptop being one such >>>>> situation. A recent comparison there between just the old and new >>>>> hotspot build: >>>>> >>>>> release new 00:04:30 >>>>> release old 00:03:10 >>>>> fastdebug new 00:04:59 >>>>> fastdebug old 00:03:37 >>>>> >>>>> Much of the extra time is spent spawning various shell processes >>>>> for book keeping, like saving failure logs, creating header >>>>> dependency files etc. >>>>> >>>>> It also takes a very long time to do a "do nothing" rebuild when >>>>> nothing has changed. On my laptop, repeating "make jimages" often >>>>> takes as long as 40 seconds to figure out that nothing needs to be >>>>> rebuilt. In this case there are several culprits. >>>>> >>>>> I have been working on improvements in these areas to reduce the >>>>> overhead. The "do nothing" rebuild of jimages is down to around 25 >>>>> seconds. A full images build is around 1-2 minutes faster from 24 >>>>> to 22 minutes, but fluctuates quite a bit. The new hotspot build >>>>> is also improved: >>>>> >>>>> release: 3:44 >>>>> fastdebug: 4:02 >>>>> >>>>> Here is a list of the kinds of changes I've made: >>>>> >>>>> * Rewrote logger.sh to use a different construct. It drastically >>>>> reduces the number of bash processes being spawned. Basically you >>>>> can pipe like this: "> >(tee logfile) 2> >(tee logfile >&2)". I >>>>> also managed to reduce the extra sed/grep commands needed for the >>>>> header dependencies even more. A side effect of this is that the >>>>> log files for each native compilation unit are always saved >>>>> instead of being deleted on successful compilation. I see no issue >>>>> with this. >>>>> >>>>> * Changed all recipes that contain echo for logging to instead use >>>>> new LogInfo macro, which in turn calls $(info ) if appropriate. >>>>> >>>>> * Changed all recipes that contain mkdir to instead use MakeDir >>>>> macro, which only executes mkdir if the directory doesn't exist. >>>>> >>>>> * In HotspotWrapper.gmk there is an optimization to avoid calling >>>>> the hotspot makefiles at all if nothing has changed. This runs a >>>>> find over the whole hotspot repository. I reduced this to only run >>>>> over src and make sub dirs to avoid the pretty large test dir >>>>> (since test/closed has grown quite a bit). >>>>> >>>>> * Split Tools.gmk into CompileTools.gmk and Tools.gmk, to avoid >>>>> having the buildtools compilation being reevaluated by all >>>>> makefiles needing the tools definitions. >>>>> >>>>> * Split Modules.gmk to avoid having the module deps generation >>>>> being reevaluated multiple times. Made the new >>>>> GenerateModuleDeps.gmk an explicit call from Init.gmk. >>>>> >>>>> Since these improvements affect much more than just the new >>>>> hotspot build, I intend to push this to JDK 9 directly. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146403 >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.01/ >>>>> >>>>> /Erik >>>> >>> >> > From erik.joelsson at oracle.com Thu Jan 14 11:06:19 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Jan 2016 12:06:19 +0100 Subject: RFR: JDK-8147086: Excluding of copy files broken after JDK-8144226 Message-ID: <5697812B.5070208@oracle.com> Since JDK-8144226, the java.desktop module is including more resource files than it used to. This is caused by a small bug in SetupJavaCompilation.gmk that fails to apply exclude patterns on files to be copied. The fix is simple: diff -r 4b01ea6c12c3 make/common/JavaCompilation.gmk --- a/make/common/JavaCompilation.gmk +++ b/make/common/JavaCompilation.gmk @@ -267,7 +267,7 @@ $1_ALL_COPIES := $$(filter $$($1_INCLUDE_PATTERN),$$($1_ALL_COPIES)) endif ifneq (,$$($1_EXCLUDE_PATTERN)) - $1_ALL_COPIES := $$(filter-out $$($1_EXCLUDES_PATTERN),$$($1_ALL_COPIES)) + $1_ALL_COPIES := $$(filter-out $$($1_EXCLUDE_PATTERN),$$($1_ALL_COPIES)) endif ifneq (,$$($1_ALL_COPIES)) # Yep, there are files to be copied! Bug: https://bugs.openjdk.java.net/browse/JDK-8147086 /Erik From magnus.ihse.bursie at oracle.com Thu Jan 14 11:06:37 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Jan 2016 12:06:37 +0100 Subject: Is there any valid reason that a debug or fastdebug build should define PRODUCT and not ASSERT during compiles? In-Reply-To: <56903337.3080802@oracle.com> References: <56903337.3080802@oracle.com> Message-ID: <5697813D.2060105@oracle.com> On 2016-01-08 23:07, Derek White wrote: > [This is likely a bug, but thought I'd ask it as a question first]. > > I'm new to jdk builds on windows, and have spent way more time than > I'd like to admit on figuring out why my fastdebug builds did not have > asserts turned on. > > The TL;DR; answer is that anyone can build this way on Windows by > simply executing this in cygwin before doing a make: > > export release="Derek is having a fun day" > > bash common/bin/jib.sh make -p windows-x86-debug -- images > > (This bug has nothing to do with jib, it's just the actual command > line I used.) > > This results in a build with both /D "DEBUG_LEVEL=\"fastdebug\"" and > /D "PRODUCT" set, because nmake.exe uppercases all environment > variables as it imports them (as a convenience to the user). > > I'd think that there is no useful purpose to supporting such a > configuration, and it's a bug to attempt it. I suggest doing an > "!ifdef RELEASE" check in windows/makefiles/debug.make and > windows/makefiles/fastdebug.make that either errors or unsets RELEASE > before including vm.make. > > Any thoughts on this? Thanks! In general, environment variables can have unexpected effects on the build, if they match a name used in the make files. There is no general solution to this problem. As for this specific problem, as Erik said in a reply to your other mail, we are currently working on replacing the use of nmake, so we are not keen on spending time fixing issues in the current nmake scripts. Since this problem has existed since the dawn of time (or so...), and it has not been reported until now, and given that there is a good workaround, I don't consider it worth fixing. I appreciate that you spent time to figure out the issue and that you reported it to us in such a polite manner! :-) I hope I don't come across as rude by dismissing your suggested fix, it's just that I want to spend all possible time on getting rid of nmake instead of fixing issues in it. /Magnus From magnus.ihse.bursie at oracle.com Thu Jan 14 11:07:14 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Jan 2016 12:07:14 +0100 Subject: RFR: JDK-8146403: Windows build can be faster In-Reply-To: <56977FF2.7050004@oracle.com> References: <568BA1D1.2060104@oracle.com> <5696398F.8040706@oracle.com> <569654D9.2090904@oracle.com> <56977BED.3040103@oracle.com> <56977E2D.70901@oracle.com> <56977FF2.7050004@oracle.com> Message-ID: <56978162.4040203@oracle.com> On 2016-01-14 12:01, Erik Joelsson wrote: > > > On 2016-01-14 11:53, Magnus Ihse Bursie wrote: >> On 2016-01-14 11:43, Erik Joelsson wrote: >>> Hello, >>> >>> Thinking more about the new bootstrap logic, I feel that I don't >>> like the solution. Here is a new patch where I only changed that >>> part. I reverted to using the -include mechanism to trigger >>> generation of module-deps.gmk, but still in a separate makefile that >>> is only included by Main.gmk. >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.03/ >> >> It looks like this version is just like the original, but you have >> moved some code from Modules.gmk to GenerateModuleDeps.gmk, but since >> both of them is included in Main.gmk, there will be no functional >> changes, just a matter of code cleanup. Or am I missing something? >> >> I'm not saying it's bad, I just understand how and if this resolves >> what you set out to solve in your first version. >> > Modules.gmk is included in many places. Each such instance would have > to evaluate if module-deps.gmk needed to be recreated or not, and in > turn run a find over the source files for the generator tool. This is > now only done in Main.gmk. Alright, I didn't see those includes. Sounds good then. Ship it! :) /Magnus > > /Erik >> /Magnus >> >>> >>> /Erik >>> >>> On 2016-01-13 14:44, Erik Joelsson wrote: >>>> Hello, >>>> >>>> New webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.02/ >>>> >>>> Fixed the below comments. Also adjusted some more gensrc log output >>>> to make it more uniform, even if it doesn't exactly address Windows >>>> performance. >>>> >>>> I also fixed a bug in the bootstrap make logic. The module-deps.gmk >>>> wasn't correctly generated in all cases. Typically when building >>>> more than one conf at a time or when doing a compare build. I added >>>> explicit calls to GenerateModuleDeps.gmk to fix this. >>>> >>>> /Erik >>>> >>>> On 2016-01-13 12:48, Magnus Ihse Bursie wrote: >>>>> Hi, >>>>> >>>>> In InitSupport.gmk, please restore the comment: >>>>> # Only do this if make has not been restarted, and if we do not >>>>> force it. >>>>> >>>>> In jdk/make/gensrc/GensrcExceptions.gmk: >>>>> The old construct resulted in the output "Generating exceptions >>>>> classes" (but a bit irregularly), could you please re-add it as a >>>>> LogInfo? >>>>> >>>>> In make/CompileTools.gmk, the copyright header says 2014, which is >>>>> at least one year too early. :-) (In fact, all modified files >>>>> should really get bumped to 2016). >>>>> >>>>> Apart from this, it looks good to me. >>>>> >>>>> /Magnus >>>>> >>>>> On 2016-01-05 11:58, Erik Joelsson wrote: >>>>>> Hello, >>>>>> >>>>>> During the hotspot makefile conversion, we have been reminded of >>>>>> inefficiencies when running make in Cygwin. We still have a >>>>>> pretty severe performance regression in the new hotspot build >>>>>> compared to the old on Windows in certain situations, my laptop >>>>>> being one such situation. A recent comparison there between just >>>>>> the old and new hotspot build: >>>>>> >>>>>> release new 00:04:30 >>>>>> release old 00:03:10 >>>>>> fastdebug new 00:04:59 >>>>>> fastdebug old 00:03:37 >>>>>> >>>>>> Much of the extra time is spent spawning various shell processes >>>>>> for book keeping, like saving failure logs, creating header >>>>>> dependency files etc. >>>>>> >>>>>> It also takes a very long time to do a "do nothing" rebuild when >>>>>> nothing has changed. On my laptop, repeating "make jimages" often >>>>>> takes as long as 40 seconds to figure out that nothing needs to >>>>>> be rebuilt. In this case there are several culprits. >>>>>> >>>>>> I have been working on improvements in these areas to reduce the >>>>>> overhead. The "do nothing" rebuild of jimages is down to around >>>>>> 25 seconds. A full images build is around 1-2 minutes faster from >>>>>> 24 to 22 minutes, but fluctuates quite a bit. The new hotspot >>>>>> build is also improved: >>>>>> >>>>>> release: 3:44 >>>>>> fastdebug: 4:02 >>>>>> >>>>>> Here is a list of the kinds of changes I've made: >>>>>> >>>>>> * Rewrote logger.sh to use a different construct. It drastically >>>>>> reduces the number of bash processes being spawned. Basically you >>>>>> can pipe like this: "> >(tee logfile) 2> >(tee logfile >&2)". I >>>>>> also managed to reduce the extra sed/grep commands needed for the >>>>>> header dependencies even more. A side effect of this is that the >>>>>> log files for each native compilation unit are always saved >>>>>> instead of being deleted on successful compilation. I see no >>>>>> issue with this. >>>>>> >>>>>> * Changed all recipes that contain echo for logging to instead >>>>>> use new LogInfo macro, which in turn calls $(info ) if appropriate. >>>>>> >>>>>> * Changed all recipes that contain mkdir to instead use MakeDir >>>>>> macro, which only executes mkdir if the directory doesn't exist. >>>>>> >>>>>> * In HotspotWrapper.gmk there is an optimization to avoid calling >>>>>> the hotspot makefiles at all if nothing has changed. This runs a >>>>>> find over the whole hotspot repository. I reduced this to only >>>>>> run over src and make sub dirs to avoid the pretty large test dir >>>>>> (since test/closed has grown quite a bit). >>>>>> >>>>>> * Split Tools.gmk into CompileTools.gmk and Tools.gmk, to avoid >>>>>> having the buildtools compilation being reevaluated by all >>>>>> makefiles needing the tools definitions. >>>>>> >>>>>> * Split Modules.gmk to avoid having the module deps generation >>>>>> being reevaluated multiple times. Made the new >>>>>> GenerateModuleDeps.gmk an explicit call from Init.gmk. >>>>>> >>>>>> Since these improvements affect much more than just the new >>>>>> hotspot build, I intend to push this to JDK 9 directly. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146403 >>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8146403/webrev.01/ >>>>>> >>>>>> /Erik >>>>> >>>> >>> >> > From magnus.ihse.bursie at oracle.com Thu Jan 14 11:07:49 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Jan 2016 12:07:49 +0100 Subject: RFR: JDK-8147086: Excluding of copy files broken after JDK-8144226 In-Reply-To: <5697812B.5070208@oracle.com> References: <5697812B.5070208@oracle.com> Message-ID: <56978185.7070402@oracle.com> On 2016-01-14 12:06, Erik Joelsson wrote: > Since JDK-8144226, the java.desktop module is including more resource > files than it used to. This is caused by a small bug in > SetupJavaCompilation.gmk that fails to apply exclude patterns on files > to be copied. The fix is simple: > > diff -r 4b01ea6c12c3 make/common/JavaCompilation.gmk > --- a/make/common/JavaCompilation.gmk > +++ b/make/common/JavaCompilation.gmk > @@ -267,7 +267,7 @@ > $1_ALL_COPIES := $$(filter $$($1_INCLUDE_PATTERN),$$($1_ALL_COPIES)) > endif > ifneq (,$$($1_EXCLUDE_PATTERN)) > - $1_ALL_COPIES := $$(filter-out > $$($1_EXCLUDES_PATTERN),$$($1_ALL_COPIES)) > + $1_ALL_COPIES := $$(filter-out > $$($1_EXCLUDE_PATTERN),$$($1_ALL_COPIES)) > endif > ifneq (,$$($1_ALL_COPIES)) > # Yep, there are files to be copied! > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147086 Looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Thu Jan 14 12:00:45 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Jan 2016 13:00:45 +0100 Subject: RFR: JDK-8147091 Remove debug output in basics.m4 Message-ID: <56978DED.30303@oracle.com> Unfortunately a piece of debug output slipped into basics.m4 some time ago. That it hasn't been discovered until now is probably proof that nobody reads the output from configure. :-& Bug: https://bugs.openjdk.java.net/browse/JDK-8147091 Diff inline: diff --git a/common/autoconf/basics.m4 b/common/autoconf/basics.m4 --- a/common/autoconf/basics.m4 +++ b/common/autoconf/basics.m4 @@ -1122,7 +1122,6 @@ # Move configure.log from current directory to the build output root if test -e ./configure.log; then - echo found it $MV -f ./configure.log "$OUTPUT_ROOT/configure.log" 2> /dev/null fi /Magnus From andreas.lundblad at oracle.com Thu Jan 14 12:23:05 2016 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Thu, 14 Jan 2016 13:23:05 +0100 Subject: javac server: No port file values materialized. on AIX In-Reply-To: <56975720.2010606@oracle.com> References: <56975720.2010606@oracle.com> Message-ID: <20160114122303.GD14798@e6430> On Thu, Jan 14, 2016 at 09:06:56AM +0100, Erik Joelsson wrote: > There is a bug for that as we see the same thing on Solaris from > time to time, as I see you know. Andreas, who is the main engineer > working on sjavac, is currently on vacation. We don't currently know > the cause of this issue. Any help would be appreciated. > > /Erik As Erik said, I'm on vacation until Monday. This issue is however currently my top priority. I'm thankful that you let me know that the fix for JDK-8145944 did not solve JDK-8145392. best regards, Andreas From erik.joelsson at oracle.com Thu Jan 14 12:55:28 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Jan 2016 13:55:28 +0100 Subject: RFR: JDK-8147091 Remove debug output in basics.m4 In-Reply-To: <56978DED.30303@oracle.com> References: <56978DED.30303@oracle.com> Message-ID: <56979AC0.5090105@oracle.com> Looks good. /Erik On 2016-01-14 13:00, Magnus Ihse Bursie wrote: > Unfortunately a piece of debug output slipped into basics.m4 some time > ago. > > That it hasn't been discovered until now is probably proof that nobody > reads the output from configure. :-& > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147091 > Diff inline: > > diff --git a/common/autoconf/basics.m4 b/common/autoconf/basics.m4 > --- a/common/autoconf/basics.m4 > +++ b/common/autoconf/basics.m4 > @@ -1122,7 +1122,6 @@ > > # Move configure.log from current directory to the build output root > if test -e ./configure.log; then > - echo found it > $MV -f ./configure.log "$OUTPUT_ROOT/configure.log" 2> /dev/null > fi > > /Magnus From thomas.stuefe at gmail.com Thu Jan 14 14:42:48 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 14 Jan 2016 15:42:48 +0100 Subject: javac server: No port file values materialized. on AIX In-Reply-To: <20160114122303.GD14798@e6430> References: <56975720.2010606@oracle.com> <20160114122303.GD14798@e6430> Message-ID: Thanks, Andreas, well, we do have a workaround. I'll wait until you find out more. Have a nice rest-of-vacation! Kind Regards, Thomas On Thu, Jan 14, 2016 at 1:23 PM, Andreas Lundblad < andreas.lundblad at oracle.com> wrote: > On Thu, Jan 14, 2016 at 09:06:56AM +0100, Erik Joelsson wrote: > > There is a bug for that as we see the same thing on Solaris from > > time to time, as I see you know. Andreas, who is the main engineer > > working on sjavac, is currently on vacation. We don't currently know > > the cause of this issue. Any help would be appreciated. > > > > /Erik > > As Erik said, I'm on vacation until Monday. > > This issue is however currently my top priority. I'm thankful that you let > me know that the fix for JDK-8145944 did not solve JDK-8145392. > > best regards, > Andreas > From swpalmer at gmail.com Thu Jan 14 14:59:42 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 14 Jan 2016 09:59:42 -0500 Subject: Configure(still?) broken on OS X In-Reply-To: <569755E6.7060208@oracle.com> References: <569755E6.7060208@oracle.com> Message-ID: I installed XQuartz, rebooted, and re-ran configure. Got the exact same error. Seems the path to freetype in XQuartz is not fixed. Scott On Thu, Jan 14, 2016 at 3:01 AM, Erik Joelsson wrote: > I believe freetype is needed on Macosx so if that is missing in > README-builds.html, that's a bug. > > I'm not a regular Macosx user so I might remember this wrong, but you can > get freetype from different sources. One is to install XQuartz. Another is > to get it from homebrew. There was some issue with Macosx 10.11 and the > path to freetype in XQuartz but I think that should be fixed now. > > /Erik > > > On 2016-01-13 22:39, Scott Palmer wrote: > >> There was a recent thread about JDK-8145206: Configure broken on Macosx >> >> I just attempted to bulid jdk9 on OS X 10.11.2 and configure failed with: >> >> configure: error: Could not find freetype! >> /Users/me/dev/openjdk9.common/autoconf/generated-configure.sh: line 82: 5: >> Bad file descriptor >> >> >> Checking README-builds.html I see that Freetype is listed as something >> that >> is needed for Linux and Solaris, but not Mac OS X. >> >> What is broken, configure or the System Setup instructions? >> >> Thanks, >> >> Scott >> > > From magnus.ihse.bursie at oracle.com Thu Jan 14 15:00:31 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Jan 2016 16:00:31 +0100 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: <57E1C404-21A6-41F7-87EF-881EDD3830C1@oracle.com> References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> <57E1C404-21A6-41F7-87EF-881EDD3830C1@oracle.com> Message-ID: <5697B80F.4050905@oracle.com> On 2015-12-18 15:11, Wang Weijun wrote: > Hi Vinnie > > I take a look and it includes a change for src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp in the Java_sun_security_mscapi_KeyStore_getKeyLength() function. > > It seems there is no sun.security.mscapi.KeyStore#getKeyLength on the java side. Is the function useless now? Max, Is your intention here that you think the patch should remove the entire Java_sun_security_mscapi_KeyStore_getKeyLength function? /Magnus > > Thanks > Max > >> On Dec 16, 2015, at 9:50 PM, Magnus Ihse Bursie wrote: >> >> There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. >> >> This patch is provided by Timo Kinnunen . I am sponsoring this patch. >> >> The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well. >> >> I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 >> >> /Magnus From magnus.ihse.bursie at oracle.com Thu Jan 14 15:05:11 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Jan 2016 16:05:11 +0100 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: <98B07F13-1D90-4DEC-AAED-D791F4666BF7@oracle.com> References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> <98B07F13-1D90-4DEC-AAED-D791F4666BF7@oracle.com> Message-ID: <5697B927.6090008@oracle.com> On 2016-01-05 03:25, Kim Barrett wrote: > On Dec 18, 2015, at 7:41 PM, Kim Barrett wrote: >> On Dec 16, 2015, at 8:50 AM, Magnus Ihse Bursie wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 >>> >>> /Magnus >> I only looked at hotspot files. >> >> [?] >> There are a couple of "TBD"s below that I need to spend more time on. >> > Back from holiday, and here?s my comments on those two TBDs Kim, Thank you for your feedback. Since I'm only the sponsor of this patch, not the developer, I'll let Timo answer your questions and discuss his choices. /Magnus > > ------------------------------------------------------------------------------ > hotspot/agent/src/share/native/sadis.c > 96 return (int)strlen(buf); > > The only call to the (file-scoped) getLastErrorString function is > Java_sun_jvm_hotspot_asm_Disassembler_load_1library, which ignores the > result. It would be better to change the return type of > getLastErrorString to void and update the return statements > accordingly. > > ------------------------------------------------------------------------------ > hotspot/src/share/vm/adlc/arena.hpp > 74 // Usual (non-placement) deallocation function to allow placement delete use size_t > 75 // See 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 2. > 76 void operator delete(void* p); > > and associated code in the .cpp file. > > I think this is another C++11 change: > http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#429 > > I think the proposed code change is OK, although the comment is > problematic: [basic.stc.dynamic.deallocation] is C++03 3.7.3.2 and > C++11 3.7.4.2. Also, the standard change that leads to this code > change is in C++11 5.3.4 [expr.new] paragraph 20 (C++02 p 19). > > Also, I *think* with the addition of the one-arg operator delete we > don't actually use the two-arg form. If so, then I suggest removing > it and the proposed new comment for the one-arg form. > > ------------------------------------------------------------------------------ > From magnus.ihse.bursie at oracle.com Thu Jan 14 15:07:33 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Jan 2016 16:07:33 +0100 Subject: Configure(still?) broken on OS X In-Reply-To: References: <569755E6.7060208@oracle.com> Message-ID: <5697B9B5.8020801@oracle.com> On 2016-01-14 15:59, Scott Palmer wrote: > I installed XQuartz, rebooted, and re-ran configure. Got the exact same > error. Seems the path to freetype in XQuartz is not fixed. How did you install XQuartz? Can you check that you indeed have freetype installed on the system, and let us know where it ended up. I think it might end up somewhere in /opt in newer releases. Once you know where you installed freetype, the short-term workaround is to provide this path to configure using --with-freetype. The long-term is that we can add some additional "well known" paths to look at by default in configure to save some typing. /Magnus > > Scott > > On Thu, Jan 14, 2016 at 3:01 AM, Erik Joelsson > wrote: > >> I believe freetype is needed on Macosx so if that is missing in >> README-builds.html, that's a bug. >> >> I'm not a regular Macosx user so I might remember this wrong, but you can >> get freetype from different sources. One is to install XQuartz. Another is >> to get it from homebrew. There was some issue with Macosx 10.11 and the >> path to freetype in XQuartz but I think that should be fixed now. >> >> /Erik >> >> >> On 2016-01-13 22:39, Scott Palmer wrote: >> >>> There was a recent thread about JDK-8145206: Configure broken on Macosx >>> >>> I just attempted to bulid jdk9 on OS X 10.11.2 and configure failed with: >>> >>> configure: error: Could not find freetype! >>> /Users/me/dev/openjdk9.common/autoconf/generated-configure.sh: line 82: 5: >>> Bad file descriptor >>> >>> >>> Checking README-builds.html I see that Freetype is listed as something >>> that >>> is needed for Linux and Solaris, but not Mac OS X. >>> >>> What is broken, configure or the System Setup instructions? >>> >>> Thanks, >>> >>> Scott >>> >> From erik.helin at oracle.com Thu Jan 14 16:03:05 2016 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 14 Jan 2016 17:03:05 +0100 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tets to build/conf/hotspot/testoutput In-Reply-To: <569720FC.7080409@oracle.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160113140405.GF17653@ehelin.jrpg.bea.com> <56969D5A.1020203@oracle.com> <569720FC.7080409@oracle.com> Message-ID: <20160114160304.GM17653@ehelin.jrpg.bea.com> On 2016-01-14, David Holmes wrote: > Sorry I don't understand the change. AFAICS ALT_OUTPUTDIR could be anything > - no guarantee that it already contains the "CONF" directory. > > Any why only change one path: > > ifdef ALT_OUTPUTDIR > ! ABS_BUILD_ROOT = $(ALT_OUTPUTDIR)/hotspot > else > ABS_BUILD_ROOT = $(TEST_ROOT)/../build/$(PLATFORM)-$(ARCH) > > ?? When do we take each path? The only "oficially" supported way of using the hotspot Makefiles is to use the Makefiles in the top-level repo (e.g. jdk9/hs-rt). The Makefiles in the top-level repo will always set ALT_OUTPUTDIR to /build/. Hence, for any developer using these Makefiles, ALT_OUTPUTDIR will always point to the current configuration. If anyone is using ALT_OUTPUTDIR in some other way, then they are "on their own" (i.e. they will have to adjust their scripts). The one exception to this is JPRT, which does not use ALT_OUTPUTDIR at all, and therefore uses the "else" branch. I don't want to change the behaviour in JPRT, therefore I only changed the "then" branch. Thanks, Erik > David > ----- > > On 14/01/2016 4:54 AM, Mikael Vidstedt wrote: > > > >The logic in this file (hotspot/test/Makefile) is very similar to that > >of jdk/test/Makefile, as a matter of fact some of it has been copy > >pasted. It would be nice if the output dir paths would be set up the > >same way in both cases, to avoid confusion and all of that. > > > >It would be even better to share the logic all together to avoid > >duplication, but that's a separate issue. > > > >Cheers, > >Mikael > > > >On 2016-01-13 06:04, Erik Helin wrote: > >>(added missing subject) > >> > >>On 2016-01-13, Erik Helin wrote: > >>>Hi all, > >>> > >>>this patch changes the output directory for hotspot's jtreg tests when > >>>run via the top-level Makefile targets such as > >>>`make test-hotspot-jtreg`. > >>> > >>>The current directory is > >>>/build//hotspot/linux-x64/testoutput > >>>(on an x86-64 machine running Linux). There is no need to place the > >>>"testoutput" directory in a directory which name is based on OS and > >>>arch, > >>>that is already done by the current configuration. Therefore, we can > >>>instead place the "testoutput" directory in > >>>/build//hotspot/, which is a more reasonable location > >>>for the output from hotspot's tests. > >>> > >>>Enhancement: > >>>https://bugs.openjdk.java.net/browse/JDK-8146985 > >>> > >>>Webrev: > >>>http://cr.openjdk.java.net/~ehelin/8146985/00/webrev > >>> > >>>Testing: > >>>- Running `make test-hotspot-jtreg` locally > >>>- JPRT (the patch does not affect JPRT since JPRT does not use > >>> ALT_OUTPUTDIR) > >>> > >>>Thanks, > >>>Erik > > From erik.helin at oracle.com Thu Jan 14 16:19:24 2016 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 14 Jan 2016 17:19:24 +0100 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tets to build/conf/hotspot/testoutput In-Reply-To: <56969D5A.1020203@oracle.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160113140405.GF17653@ehelin.jrpg.bea.com> <56969D5A.1020203@oracle.com> Message-ID: <20160114161924.GN17653@ehelin.jrpg.bea.com> On 2016-01-13, Mikael Vidstedt wrote: > The logic in this file (hotspot/test/Makefile) is very similar to that of > jdk/test/Makefile, as a matter of fact some of it has been copy pasted. The benefit is that if you learn one of the Makefiles, you can quickly pick learn the other one ;) On 2016-01-13, Mikael Vidstedt wrote: > It would be nice if the output dir paths would be set up the same way > in both cases, to avoid confusion and all of that. Yep, agree, and looking at jdk/test/Makefile, it does things slightly different. When running one of jtreg groups jdk_*, core_* or svc_* via the top-level Makefiles, then the results will end up in: /build//testoutput/ Given the current feedback, the proposed change is to put the hotspot results in: /build//testoutput/hotspot We could align jdk/test/Makefile and hotspot/test/Makefile by having the hotspot results in /build/testoutput/ as well. The jtreg groups with identical suffixes are already prefixed by their folder (e.g. jdk_svc, hotspot_svc), so there shouldn't be any name clashes. I will send out a new patch soon. Thanks, Erik > It would be even better to share the logic all together to avoid > duplication, but that's a separate issue. > > Cheers, > Mikael > > On 2016-01-13 06:04, Erik Helin wrote: > >(added missing subject) > > > >On 2016-01-13, Erik Helin wrote: > >>Hi all, > >> > >>this patch changes the output directory for hotspot's jtreg tests when > >>run via the top-level Makefile targets such as > >>`make test-hotspot-jtreg`. > >> > >>The current directory is > >>/build//hotspot/linux-x64/testoutput > >>(on an x86-64 machine running Linux). There is no need to place the > >>"testoutput" directory in a directory which name is based on OS and arch, > >>that is already done by the current configuration. Therefore, we can > >>instead place the "testoutput" directory in > >>/build//hotspot/, which is a more reasonable location > >>for the output from hotspot's tests. > >> > >>Enhancement: > >>https://bugs.openjdk.java.net/browse/JDK-8146985 > >> > >>Webrev: > >>http://cr.openjdk.java.net/~ehelin/8146985/00/webrev > >> > >>Testing: > >>- Running `make test-hotspot-jtreg` locally > >>- JPRT (the patch does not affect JPRT since JPRT does not use > >> ALT_OUTPUTDIR) > >> > >>Thanks, > >>Erik > From swpalmer at gmail.com Thu Jan 14 16:46:39 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 14 Jan 2016 11:46:39 -0500 Subject: Configure(still?) broken on OS X In-Reply-To: <5697B9B5.8020801@oracle.com> References: <569755E6.7060208@oracle.com> <5697B9B5.8020801@oracle.com> Message-ID: On Thu, Jan 14, 2016 at 10:07 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2016-01-14 15:59, Scott Palmer wrote: > >> I installed XQuartz, rebooted, and re-ran configure. Got the exact same >> error. Seems the path to freetype in XQuartz is not fixed. >> > > How did you install XQuartz? > I ran the installer package for XQuartz 2.7.8 that I grabbed from http://www.xquartz.org > > Can you check that you indeed have freetype installed on the system, and > let us know where it ended up. I think it might end up somewhere in /opt in > newer releases. > I found this: /opt/X11/include/freetype2 /opt/X11/lib/libfreetype.6.dylib /opt/X11/lib/libfreetype.dylib > > Once you know where you installed freetype, the short-term workaround is > to provide this path to configure using --with-freetype. The long-term is > that we can add some additional "well known" paths to look at by default in > configure to save some typing. Thanks, looks like this does the trick: ./configure --with-freetype=/opt/X11 Regards, Scott From swpalmer at gmail.com Thu Jan 14 18:32:38 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 14 Jan 2016 13:32:38 -0500 Subject: Build errors on OS X "Failed module access verification" Message-ID: I managed to get configure working by installing freetype via XQuartz and forcing it to be found with ./configure --with-freetype=/opt/X11 I'm building on OS X 10.11.2. The table in Appendix C: Build Environments or the README-builds.html file says "Xcode 6.3 or newer", but Xcode 7 resulted in a couple build errors*. Other sections of README-build.html say only "Xcode 6.3" and "Be sure to use the right Xcode". So I installed the command line tools for 6.3.2 and that cleared up the 2 compile errors I got with Xcode 7. After configuring I ran "make all" Now I'm getting some other errors that appear to be fairly far into the build process: Creating jre jimage duplicate resource "META-INF/services/sun.jvmstat.monitor.MonitoredHostService", skipping duplicate resource "META-INF/services/com.sun.jdi.connect.Connector", skipping duplicate resource "META-INF/services/sun.jvmstat.monitor.MonitoredHostService", skipping inaccessible reference: com.sun.tools.attach.AgentInitializationException (jdk.attach) -> jdk.Exported (java.base) inaccessible reference: com.sun.tools.attach.AgentLoadException (jdk.attach) -> jdk.Exported (java.base) ... ... inaccessible reference: jdk.dynalink.linker.support.package-info (jdk.dynalink) -> jdk.Exported (java.base) inaccessible reference: jdk.dynalink.package-info (jdk.dynalink) -> jdk.Exported (java.base) inaccessible reference: jdk.dynalink.support.package-info (jdk.dynalink) -> jdk.Exported (java.base) ERROR: Failed module access verification make[3]: *** [checkdeps] Error 1 make[2]: *** [verify-modules] Error 2 make[2]: *** Waiting for unfinished jobs.... Which looks like this issue: https://bugs.openjdk.java.net/browse/JDK-8067479 However that issue is marked as fixed. Am I missing something? Thanks, Scott * These are the compiler errors when using Xcode 7, if anyone cares: === Output from failing command(s) repeated here === * For target BUILD_LIBAWT_LWAWT_AWTView.m: /Users/spalmer/dev/openjdk9/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:627:36: error: null passed to a callee that requires a non-null argument [-Werror,-Wnonnull] NSData *rtfdData = [styledText RTFDFromRange:NSMakeRange(0, [styledText length]) documentAttributes:nil]; ^ ~~~ 1 error generated. * For target BUILD_LIBSA_MacosxDebuggerLocal.m: /Users/spalmer/dev/openjdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:691:21: error: 'ePtAttachDeprecated' is deprecated: PT_ATTACH is deprecated. See PT_ATTACHEXC [-Werror,-Wdeprecated-declarations] if ((res = ptrace(PT_ATTACH, pid, 0, 0)) < 0) { ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/sys/ptrace.h:85:19: note: expanded from macro 'PT_ATTACH' #define PT_ATTACH ePtAttachDeprecated /* trace some running process */ ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/sys/ptrace.h:71:2: note: 'ePtAttachDeprecated' has been explicitly marked deprecated here ePtAttachDeprecated __deprecated_enum_msg("PT_ATTACH is deprecated. See PT_ATTACHEXC") = 10 ^ 1 error generated. === End of repeated output === From magnus.ihse.bursie at oracle.com Thu Jan 14 22:30:49 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Jan 2016 23:30:49 +0100 Subject: Build errors on OS X "Failed module access verification" In-Reply-To: References: Message-ID: <56982199.4020102@oracle.com> On 2016-01-14 19:32, Scott Palmer wrote: > I managed to get configure working by installing freetype via XQuartz and > forcing it to be found with ./configure --with-freetype=/opt/X11 > > I'm building on OS X 10.11.2. > > The table in Appendix C: Build Environments or the README-builds.html file > says "Xcode 6.3 or newer", but Xcode 7 resulted in a couple build errors*. > Other sections of README-build.html say only "Xcode 6.3" and "Be sure to > use the right Xcode". So I installed the command line tools for 6.3.2 and > that cleared up the 2 compile errors I got with Xcode 7. > > After configuring I ran "make all" > > Now I'm getting some other errors that appear to be fairly far into the > build process: > > Creating jre jimage > duplicate resource > "META-INF/services/sun.jvmstat.monitor.MonitoredHostService", skipping > duplicate resource "META-INF/services/com.sun.jdi.connect.Connector", > skipping > duplicate resource > "META-INF/services/sun.jvmstat.monitor.MonitoredHostService", skipping > inaccessible reference: com.sun.tools.attach.AgentInitializationException > (jdk.attach) -> jdk.Exported (java.base) > inaccessible reference: com.sun.tools.attach.AgentLoadException > (jdk.attach) -> jdk.Exported (java.base) > ... ... > inaccessible reference: jdk.dynalink.linker.support.package-info > (jdk.dynalink) -> jdk.Exported (java.base) > inaccessible reference: jdk.dynalink.package-info (jdk.dynalink) -> > jdk.Exported (java.base) > inaccessible reference: jdk.dynalink.support.package-info (jdk.dynalink) -> > jdk.Exported (java.base) > ERROR: Failed module access verification In JDK-8049422, jdk.Exported was removed. It seems there are broken references to jdk.Export. Could it be that your forest is not correctly synced? I suggest trying, in order, 1) bash get_source.sh and rebuild 2) make clean and rebuild 3) re-clone the forest /Magnus > make[3]: *** [checkdeps] Error 1 > make[2]: *** [verify-modules] Error 2 > make[2]: *** Waiting for unfinished jobs.... > > > Which looks like this issue: > https://bugs.openjdk.java.net/browse/JDK-8067479 > However that issue is marked as fixed. Am I missing something? > > > Thanks, > > Scott > > * These are the compiler errors when using Xcode 7, if anyone cares: > === Output from failing command(s) repeated here === > * For target BUILD_LIBAWT_LWAWT_AWTView.m: > /Users/spalmer/dev/openjdk9/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:627:36: > error: null passed to a callee that requires a non-null argument > [-Werror,-Wnonnull] > NSData *rtfdData = [styledText RTFDFromRange:NSMakeRange(0, [styledText > length]) documentAttributes:nil]; > ^ > ~~~ > 1 error generated. > * For target BUILD_LIBSA_MacosxDebuggerLocal.m: > /Users/spalmer/dev/openjdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:691:21: > error: 'ePtAttachDeprecated' is deprecated: PT_ATTACH is deprecated. See > PT_ATTACHEXC [-Werror,-Wdeprecated-declarations] > if ((res = ptrace(PT_ATTACH, pid, 0, 0)) < 0) { > ^ > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/sys/ptrace.h:85:19: > note: expanded from macro 'PT_ATTACH' > #define PT_ATTACH ePtAttachDeprecated /* trace some running > process */ > ^ > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/sys/ptrace.h:71:2: > note: 'ePtAttachDeprecated' has been explicitly marked deprecated here > ePtAttachDeprecated __deprecated_enum_msg("PT_ATTACH is deprecated. > See PT_ATTACHEXC") = 10 > ^ > 1 error generated. > === End of repeated output === From weijun.wang at oracle.com Fri Jan 15 00:39:30 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 15 Jan 2016 08:39:30 +0800 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: <5697B80F.4050905@oracle.com> References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> <57E1C404-21A6-41F7-87EF-881EDD3830C1@oracle.com> <5697B80F.4050905@oracle.com> Message-ID: <1411F578-C3A7-473D-9407-F10E018DF75E@oracle.com> > On Jan 14, 2016, at 11:00 PM, Magnus Ihse Bursie wrote: > > On 2015-12-18 15:11, Wang Weijun wrote: >> Hi Vinnie >> >> I take a look and it includes a change for src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp in the Java_sun_security_mscapi_KeyStore_getKeyLength() function. >> >> It seems there is no sun.security.mscapi.KeyStore#getKeyLength on the java side. Is the function useless now? > > Max, > > Is your intention here that you think the patch should remove the entire Java_sun_security_mscapi_KeyStore_getKeyLength function? Yes, I hope so. --Max > > /Magnus > >> >> Thanks >> Max >> >>> On Dec 16, 2015, at 9:50 PM, Magnus Ihse Bursie wrote: >>> >>> There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. >>> >>> This patch is provided by Timo Kinnunen . I am sponsoring this patch. >>> >>> The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well. >>> >>> I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 >>> >>> /Magnus > From david.holmes at oracle.com Fri Jan 15 02:18:34 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Jan 2016 12:18:34 +1000 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tets to build/conf/hotspot/testoutput In-Reply-To: <20160114160304.GM17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160113140405.GF17653@ehelin.jrpg.bea.com> <56969D5A.1020203@oracle.com> <569720FC.7080409@oracle.com> <20160114160304.GM17653@ehelin.jrpg.bea.com> Message-ID: <569856FA.40702@oracle.com> On 15/01/2016 2:03 AM, Erik Helin wrote: > On 2016-01-14, David Holmes wrote: >> Sorry I don't understand the change. AFAICS ALT_OUTPUTDIR could be anything >> - no guarantee that it already contains the "CONF" directory. >> >> Any why only change one path: >> >> ifdef ALT_OUTPUTDIR >> ! ABS_BUILD_ROOT = $(ALT_OUTPUTDIR)/hotspot >> else >> ABS_BUILD_ROOT = $(TEST_ROOT)/../build/$(PLATFORM)-$(ARCH) >> >> ?? When do we take each path? > > The only "oficially" supported way of using the hotspot Makefiles is to > use the Makefiles in the top-level repo (e.g. jdk9/hs-rt). The Makefiles > in the top-level repo will always set ALT_OUTPUTDIR to > /build/. Hence, for any developer using these > Makefiles, ALT_OUTPUTDIR will always point to the current configuration. You're right - what I should have said is that there is no guarantee that the conf directory contains os-cpu. But regardless, for any given conf there is only one os-cpu pair so having that in the path is pointless, so the change is fine. > If anyone is using ALT_OUTPUTDIR in some other way, then they are "on > their own" (i.e. they will have to adjust their scripts). > > The one exception to this is JPRT, which does not use ALT_OUTPUTDIR at > all, and therefore uses the "else" branch. I don't want to change the > behaviour in JPRT, therefore I only changed the "then" branch. Okay -makes good sense. Thanks, David > Thanks, > Erik > >> David >> ----- >> >> On 14/01/2016 4:54 AM, Mikael Vidstedt wrote: >>> >>> The logic in this file (hotspot/test/Makefile) is very similar to that >>> of jdk/test/Makefile, as a matter of fact some of it has been copy >>> pasted. It would be nice if the output dir paths would be set up the >>> same way in both cases, to avoid confusion and all of that. >>> >>> It would be even better to share the logic all together to avoid >>> duplication, but that's a separate issue. >>> >>> Cheers, >>> Mikael >>> >>> On 2016-01-13 06:04, Erik Helin wrote: >>>> (added missing subject) >>>> >>>> On 2016-01-13, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> this patch changes the output directory for hotspot's jtreg tests when >>>>> run via the top-level Makefile targets such as >>>>> `make test-hotspot-jtreg`. >>>>> >>>>> The current directory is >>>>> /build//hotspot/linux-x64/testoutput >>>>> (on an x86-64 machine running Linux). There is no need to place the >>>>> "testoutput" directory in a directory which name is based on OS and >>>>> arch, >>>>> that is already done by the current configuration. Therefore, we can >>>>> instead place the "testoutput" directory in >>>>> /build//hotspot/, which is a more reasonable location >>>>> for the output from hotspot's tests. >>>>> >>>>> Enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8146985 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >>>>> >>>>> Testing: >>>>> - Running `make test-hotspot-jtreg` locally >>>>> - JPRT (the patch does not affect JPRT since JPRT does not use >>>>> ALT_OUTPUTDIR) >>>>> >>>>> Thanks, >>>>> Erik >>> From volker.simonis at gmail.com Fri Jan 15 09:59:08 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 15 Jan 2016 10:59:08 +0100 Subject: javac server: No port file values materialized. on AIX In-Reply-To: <20160114122303.GD14798@e6430> References: <56975720.2010606@oracle.com> <20160114122303.GD14798@e6430> Message-ID: Maybe the timeout of five seconds is too small? Our AIX boxes are not the fastest and we also have a lot of stuff on NFS shares. I recently saw this one: [CLIENT] Exception caught: java.io.IOException: No port file values materialized. Giving up after 6676 ms Normally the timeout should be just about a little more than 5 seconds but here the exception reports more than 6 seconds which might be a hint that the machine was severely overloaded. Regards, Volker On Thu, Jan 14, 2016 at 1:23 PM, Andreas Lundblad wrote: > On Thu, Jan 14, 2016 at 09:06:56AM +0100, Erik Joelsson wrote: >> There is a bug for that as we see the same thing on Solaris from >> time to time, as I see you know. Andreas, who is the main engineer >> working on sjavac, is currently on vacation. We don't currently know >> the cause of this issue. Any help would be appreciated. >> >> /Erik > > As Erik said, I'm on vacation until Monday. > > This issue is however currently my top priority. I'm thankful that you let me know that the fix for JDK-8145944 did not solve JDK-8145392. > > best regards, > Andreas From erik.helin at oracle.com Fri Jan 15 16:13:29 2016 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 15 Jan 2016 17:13:29 +0100 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tests In-Reply-To: <20160113140128.GE17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> Message-ID: <20160115161329.GQ17653@ehelin.jrpg.bea.com> Hi all, I have updated the patch based on feedback and comments. hotspot/test/Makefile is now aligned with jdk/test/Makefile and now stores the ouput from the jtreg tests in: /build//testoutput/ Since the jtreg groups are prefixed with the name of the repository, e.g. hotspot_svc, jdk_svc, there won't be any name clashes. Webrev: http://cr.openjdk.java.net/~ehelin/8146985/01/ Testing: - Running `make test-hotspot-jtreg` and verified that is uses the correct directory for test output. - Running JPRT and verified that it works with the new directory name. Since JPRT does not use ALT_OUTPUTDIR, the output will be stored in build/-/testoutput/ which JPRT seems to handle just fine. Thanks, Erik On 2016-01-13, Erik Helin wrote: > Hi all, > > this patch changes the output directory for hotspot's jtreg tests when > run via the top-level Makefile targets such as > `make test-hotspot-jtreg`. > > The current directory is > /build//hotspot/linux-x64/testoutput > (on an x86-64 machine running Linux). There is no need to place the > "testoutput" directory in a directory which name is based on OS and arch, > that is already done by the current configuration. Therefore, we can > instead place the "testoutput" directory in > /build//hotspot/, which is a more reasonable location > for the output from hotspot's tests. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8146985 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146985/00/webrev > > Testing: > - Running `make test-hotspot-jtreg` locally > - JPRT (the patch does not affect JPRT since JPRT does not use > ALT_OUTPUTDIR) > > Thanks, > Erik From erik.joelsson at oracle.com Fri Jan 15 16:17:26 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Jan 2016 17:17:26 +0100 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tests In-Reply-To: <20160115161329.GQ17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160115161329.GQ17653@ehelin.jrpg.bea.com> Message-ID: <56991B96.3070801@oracle.com> Looks good. /Erik On 2016-01-15 17:13, Erik Helin wrote: > Hi all, > > I have updated the patch based on feedback and comments. > hotspot/test/Makefile is now aligned with jdk/test/Makefile and now > stores the ouput from the jtreg tests in: > /build//testoutput/ > Since the jtreg groups are prefixed with the name of the repository, > e.g. hotspot_svc, jdk_svc, there won't be any name clashes. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146985/01/ > > Testing: > - Running `make test-hotspot-jtreg` and verified that is uses the > correct directory for test output. > - Running JPRT and verified that it works with the new directory name. > Since JPRT does not use ALT_OUTPUTDIR, the output will be stored in > build/-/testoutput/ > which JPRT seems to handle just fine. > > Thanks, > Erik > > On 2016-01-13, Erik Helin wrote: >> Hi all, >> >> this patch changes the output directory for hotspot's jtreg tests when >> run via the top-level Makefile targets such as >> `make test-hotspot-jtreg`. >> >> The current directory is >> /build//hotspot/linux-x64/testoutput >> (on an x86-64 machine running Linux). There is no need to place the >> "testoutput" directory in a directory which name is based on OS and arch, >> that is already done by the current configuration. Therefore, we can >> instead place the "testoutput" directory in >> /build//hotspot/, which is a more reasonable location >> for the output from hotspot's tests. >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8146985 >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >> >> Testing: >> - Running `make test-hotspot-jtreg` locally >> - JPRT (the patch does not affect JPRT since JPRT does not use >> ALT_OUTPUTDIR) >> >> Thanks, >> Erik From swpalmer at gmail.com Fri Jan 15 18:56:06 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 15 Jan 2016 13:56:06 -0500 Subject: Build errors on OS X "Failed module access verification" In-Reply-To: <56982199.4020102@oracle.com> References: <56982199.4020102@oracle.com> Message-ID: <4E472786-3827-4BAA-AF7C-1F9CF0148F43@gmail.com> > On Jan 14, 2016, at 5:30 PM, Magnus Ihse Bursie wrote: > >> On 2016-01-14 19:32, Scott Palmer wrote: >> I managed to get configure working by installing freetype via XQuartz and >> forcing it to be found with ./configure --with-freetype=/opt/X11 >> >> I'm building on OS X 10.11.2. >> >> The table in Appendix C: Build Environments or the README-builds.html file >> says "Xcode 6.3 or newer", but Xcode 7 resulted in a couple build errors*. >> Other sections of README-build.html say only "Xcode 6.3" and "Be sure to >> use the right Xcode". So I installed the command line tools for 6.3.2 and >> that cleared up the 2 compile errors I got with Xcode 7. >> >> After configuring I ran "make all" >> >> Now I'm getting some other errors that appear to be fairly far into the >> build process: >> >> Creating jre jimage >> duplicate resource >> "META-INF/services/sun.jvmstat.monitor.MonitoredHostService", skipping >> duplicate resource "META-INF/services/com.sun.jdi.connect.Connector", >> skipping >> duplicate resource >> "META-INF/services/sun.jvmstat.monitor.MonitoredHostService", skipping >> inaccessible reference: com.sun.tools.attach.AgentInitializationException >> (jdk.attach) -> jdk.Exported (java.base) >> inaccessible reference: com.sun.tools.attach.AgentLoadException >> (jdk.attach) -> jdk.Exported (java.base) >> ... ... >> inaccessible reference: jdk.dynalink.linker.support.package-info >> (jdk.dynalink) -> jdk.Exported (java.base) >> inaccessible reference: jdk.dynalink.package-info (jdk.dynalink) -> >> jdk.Exported (java.base) >> inaccessible reference: jdk.dynalink.support.package-info (jdk.dynalink) -> >> jdk.Exported (java.base) >> ERROR: Failed module access verification > > In JDK-8049422, jdk.Exported was removed. It seems there are broken references to jdk.Export. Could it be that your forest is not correctly synced? I suggest trying, in order, > 1) bash get_source.sh and rebuild > 2) make clean and rebuild > 3) re-clone the forest > > /Magnus That must have been it. My clone was only a few days old, and I tried a make clean once already, but another make clean and get_source.sh seemed to have fixed it. Thank you, Scott From mikael.vidstedt at oracle.com Fri Jan 15 19:53:21 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 15 Jan 2016 11:53:21 -0800 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tests In-Reply-To: <20160115161329.GQ17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160115161329.GQ17653@ehelin.jrpg.bea.com> Message-ID: <56994E31.7050600@oracle.com> Looks good! I suggest as a follow up change to align the variable names and the (JPRT) "else" part with jdk/test/Makefile. Cheers, Mikael On 2016-01-15 08:13, Erik Helin wrote: > Hi all, > > I have updated the patch based on feedback and comments. > hotspot/test/Makefile is now aligned with jdk/test/Makefile and now > stores the ouput from the jtreg tests in: > /build//testoutput/ > Since the jtreg groups are prefixed with the name of the repository, > e.g. hotspot_svc, jdk_svc, there won't be any name clashes. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146985/01/ > > Testing: > - Running `make test-hotspot-jtreg` and verified that is uses the > correct directory for test output. > - Running JPRT and verified that it works with the new directory name. > Since JPRT does not use ALT_OUTPUTDIR, the output will be stored in > build/-/testoutput/ > which JPRT seems to handle just fine. > > Thanks, > Erik > > On 2016-01-13, Erik Helin wrote: >> Hi all, >> >> this patch changes the output directory for hotspot's jtreg tests when >> run via the top-level Makefile targets such as >> `make test-hotspot-jtreg`. >> >> The current directory is >> /build//hotspot/linux-x64/testoutput >> (on an x86-64 machine running Linux). There is no need to place the >> "testoutput" directory in a directory which name is based on OS and arch, >> that is already done by the current configuration. Therefore, we can >> instead place the "testoutput" directory in >> /build//hotspot/, which is a more reasonable location >> for the output from hotspot's tests. >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8146985 >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >> >> Testing: >> - Running `make test-hotspot-jtreg` locally >> - JPRT (the patch does not affect JPRT since JPRT does not use >> ALT_OUTPUTDIR) >> >> Thanks, >> Erik From andreas.lundblad at oracle.com Sun Jan 17 17:08:11 2016 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Sun, 17 Jan 2016 18:08:11 +0100 Subject: javac server: No port file values materialized. on AIX In-Reply-To: References: <56975720.2010606@oracle.com> <20160114122303.GD14798@e6430> Message-ID: <20160117170810.GA26924@e6430> On Fri, Jan 15, 2016 at 10:59:08AM +0100, Volker Simonis wrote: > Maybe the timeout of five seconds is too small? > > Our AIX boxes are not the fastest and we also have a lot of stuff on NFS shares. > > I recently saw this one: > > [CLIENT] Exception caught: java.io.IOException: No port file values > materialized. Giving up after 6676 ms > > Normally the timeout should be just about a little more than 5 seconds > but here the exception reports more than 6 seconds which might be a > hint that the machine was severely overloaded. > > Regards, > Volker Interesting observation. The code for waiting for valid port file values basically looks like for (int i = 0; i < 10; i++) { checkPortFile(); if (successful) break; sleep(500); } so the fact that it even reaches 6676 ms looks suspicious when it comes to load. -- Andreas From david.holmes at oracle.com Mon Jan 18 07:35:01 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Jan 2016 17:35:01 +1000 Subject: javac server: No port file values materialized. on AIX In-Reply-To: <20160117170810.GA26924@e6430> References: <56975720.2010606@oracle.com> <20160114122303.GD14798@e6430> <20160117170810.GA26924@e6430> Message-ID: <569C95A5.50409@oracle.com> On 18/01/2016 3:08 AM, Andreas Lundblad wrote: > On Fri, Jan 15, 2016 at 10:59:08AM +0100, Volker Simonis wrote: >> Maybe the timeout of five seconds is too small? >> >> Our AIX boxes are not the fastest and we also have a lot of stuff on NFS shares. >> >> I recently saw this one: >> >> [CLIENT] Exception caught: java.io.IOException: No port file values >> materialized. Giving up after 6676 ms >> >> Normally the timeout should be just about a little more than 5 seconds >> but here the exception reports more than 6 seconds which might be a >> hint that the machine was severely overloaded. >> >> Regards, >> Volker > > Interesting observation. The code for waiting for valid port file values basically looks like > > for (int i = 0; i < 10; i++) { > checkPortFile(); > if (successful) > break; > sleep(500); > } > > so the fact that it even reaches 6676 ms looks suspicious when it comes to load. Why? Under load those sleep(500)'s might not return for much longer; and the whole things might be time preempted at any point for an extended period of time. David ----- > -- Andreas > From volker.simonis at gmail.com Mon Jan 18 08:08:32 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 18 Jan 2016 09:08:32 +0100 Subject: javac server: No port file values materialized. on AIX In-Reply-To: <569C95A5.50409@oracle.com> References: <56975720.2010606@oracle.com> <20160114122303.GD14798@e6430> <20160117170810.GA26924@e6430> <569C95A5.50409@oracle.com> Message-ID: On Mon, Jan 18, 2016 at 8:35 AM, David Holmes wrote: > On 18/01/2016 3:08 AM, Andreas Lundblad wrote: >> >> On Fri, Jan 15, 2016 at 10:59:08AM +0100, Volker Simonis wrote: >>> >>> Maybe the timeout of five seconds is too small? >>> >>> Our AIX boxes are not the fastest and we also have a lot of stuff on NFS >>> shares. >>> >>> I recently saw this one: >>> >>> [CLIENT] Exception caught: java.io.IOException: No port file values >>> materialized. Giving up after 6676 ms >>> >>> Normally the timeout should be just about a little more than 5 seconds >>> but here the exception reports more than 6 seconds which might be a >>> hint that the machine was severely overloaded. >>> >>> Regards, >>> Volker >> >> >> Interesting observation. The code for waiting for valid port file values >> basically looks like >> >> for (int i = 0; i < 10; i++) { >> checkPortFile(); >> if (successful) >> break; >> sleep(500); >> } >> >> so the fact that it even reaches 6676 ms looks suspicious when it comes to >> load. > > > Why? Under load those sleep(500)'s might not return for much longer; and the > whole things might be time preempted at any point for an extended period of > time. Yes, exactly. What about putting another loop around this loop which prints a warning to stdout (e.g. "..trying to connect to sjavac server since X seconds") for another five or so times. We could also print the system load [1] although I'm not sure it's worth it. On our AIX machines it is often a network/NFS problem which causes long startup times of new executables and this won't be observable by looking at the system load (but it may at least give a hint'). [1] http://docs.oracle.com/javase/6/docs/api/java/lang/management/OperatingSystemMXBean.html#getSystemLoadAverage%28%29 > > David > ----- > > >> -- Andreas >> > From andreas.lundblad at oracle.com Mon Jan 18 14:34:42 2016 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Mon, 18 Jan 2016 15:34:42 +0100 Subject: javac server: No port file values materialized. on AIX In-Reply-To: References: <56975720.2010606@oracle.com> <20160114122303.GD14798@e6430> <20160117170810.GA26924@e6430> <569C95A5.50409@oracle.com> Message-ID: <20160118143441.GA13405@e6430> > >> Interesting observation. The code for waiting for valid port file values > >> basically looks like > >> > >> for (int i = 0; i < 10; i++) { > >> checkPortFile(); > >> if (successful) > >> break; > >> sleep(500); > >> } > >> > >> so the fact that it even reaches 6676 ms looks suspicious when it comes to > >> load. > > > > > > Why? Under load those sleep(500)'s might not return for much longer; and the > > whole things might be time preempted at any point for an extended period of > > time. What I meant was that the fact that the code takes 6676 ms to complete increases my suspicion about it being due to a load issue. > What about putting another loop around this loop which prints a > warning to stdout (e.g. "..trying to connect to sjavac server since X > seconds") for another five or so times. We could also print the system > load [1] although I'm not sure it's worth it. On our AIX machines it > is often a network/NFS problem which causes long startup times of new > executables and this won't be observable by looking at the system load > (but it may at least give a hint'). > > [1] http://docs.oracle.com/javase/6/docs/api/java/lang/management/OperatingSystemMXBean.html#getSystemLoadAverage%28%29 I don't think a loop around the loop is necessary. The actual code (which is slightly different from the snippet I posted above) already prints a message between each attempt. I was thinking of just bumping the timeout from 5 seconds to, say, 60 seconds. If it's a load issue, we should se something like "Port file values found after 9000 ms", in which case we know for sure that it was a premature timeout issue. If no port files materialize after >60 seconds, we can probably safely assume that the issue is due to something else. -- Andreas From volker.simonis at gmail.com Mon Jan 18 14:39:39 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 18 Jan 2016 15:39:39 +0100 Subject: javac server: No port file values materialized. on AIX In-Reply-To: <20160118143441.GA13405@e6430> References: <56975720.2010606@oracle.com> <20160114122303.GD14798@e6430> <20160117170810.GA26924@e6430> <569C95A5.50409@oracle.com> <20160118143441.GA13405@e6430> Message-ID: On Mon, Jan 18, 2016 at 3:34 PM, Andreas Lundblad wrote: >> >> Interesting observation. The code for waiting for valid port file values >> >> basically looks like >> >> >> >> for (int i = 0; i < 10; i++) { >> >> checkPortFile(); >> >> if (successful) >> >> break; >> >> sleep(500); >> >> } >> >> >> >> so the fact that it even reaches 6676 ms looks suspicious when it comes to >> >> load. >> > >> > >> > Why? Under load those sleep(500)'s might not return for much longer; and the >> > whole things might be time preempted at any point for an extended period of >> > time. > > What I meant was that the fact that the code takes 6676 ms to complete increases my suspicion about it being due to a load issue. > > >> What about putting another loop around this loop which prints a >> warning to stdout (e.g. "..trying to connect to sjavac server since X >> seconds") for another five or so times. We could also print the system >> load [1] although I'm not sure it's worth it. On our AIX machines it >> is often a network/NFS problem which causes long startup times of new >> executables and this won't be observable by looking at the system load >> (but it may at least give a hint'). >> >> [1] http://docs.oracle.com/javase/6/docs/api/java/lang/management/OperatingSystemMXBean.html#getSystemLoadAverage%28%29 > > I don't think a loop around the loop is necessary. The actual code (which is slightly different from the snippet I posted above) already prints a message between each attempt. > > I was thinking of just bumping the timeout from 5 seconds to, say, 60 seconds. If it's a load issue, we should se something like "Port file values found after 9000 ms", in which case we know for sure that it was a premature timeout issue. If no port files materialize after >60 seconds, we can probably safely assume that the issue is due to something else. > Sounds good. Let's try it. > -- Andreas From erik.joelsson at oracle.com Tue Jan 19 10:31:09 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 19 Jan 2016 11:31:09 +0100 Subject: RFR: JDK-8147449: sjavac builds of jdk9/dev with closed sources broken Message-ID: <569E106D.7030300@oracle.com> Hello, Please review this fix in the makefiles for using sjavac. The include/exclude mechanism in sjavac has changed. We used to sometimes exclude files using a full absolute path. This no longer works. The same thing can be achieved by splitting up the source roots argument to sjavac in separate -src arguments and then filter includes and excludes that are unique to a specific source root. Since this risks making command lines much longer, I also added a conditional ListPathsSafely/@file construct. Bug: https://bugs.openjdk.java.net/browse/JDK-8147449 Webrev: http://cr.openjdk.java.net/~erikj/8147449/webrev.01/ /Erik From magnus.ihse.bursie at oracle.com Tue Jan 19 13:29:33 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 19 Jan 2016 14:29:33 +0100 Subject: RFR: JDK-8147449: sjavac builds of jdk9/dev with closed sources broken In-Reply-To: <569E106D.7030300@oracle.com> References: <569E106D.7030300@oracle.com> Message-ID: <569E3A3D.1010101@oracle.com> On 2016-01-19 11:31, Erik Joelsson wrote: > Hello, > > Please review this fix in the makefiles for using sjavac. The > include/exclude mechanism in sjavac has changed. We used to sometimes > exclude files using a full absolute path. This no longer works. The > same thing can be achieved by splitting up the source roots argument > to sjavac in separate -src arguments and then filter includes and > excludes that are unique to a specific source root. Since this risks > making command lines much longer, I also added a conditional > ListPathsSafely/@file construct. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147449 > Webrev: http://cr.openjdk.java.net/~erikj/8147449/webrev.01/ It's a bit head-ache-inducing (not your fault, though!) but it looks correct to me. /Magnus From david.dehaven at oracle.com Tue Jan 19 21:56:30 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 19 Jan 2016 13:56:30 -0800 Subject: Configure(still?) broken on OS X In-Reply-To: References: <569755E6.7060208@oracle.com> <5697B9B5.8020801@oracle.com> Message-ID: >> Once you know where you installed freetype, the short-term workaround is >> to provide this path to configure using --with-freetype. The long-term is >> that we can add some additional "well known" paths to look at by default in >> configure to save some typing. > > > Thanks, looks like this does the trick: > > ./configure --with-freetype=/opt/X11 This came up a while back, probably on another list... XQuartz had to change the install location due to 10.11 not allowing installation to /usr/X11, so our configure script should be updated to also check in /opt/X11 now. I don't know if a bug was ever filed for this or not. To answer the earlier question: Yes, freetype is required for OpenJDK builds on Mac. -DrD- From david.dehaven at oracle.com Tue Jan 19 22:00:53 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 19 Jan 2016 14:00:53 -0800 Subject: Configure(still?) broken on OS X In-Reply-To: References: <569755E6.7060208@oracle.com> <5697B9B5.8020801@oracle.com> Message-ID: <7D4506AF-6FBA-4622-9DF8-854846C5CB63@oracle.com> >> Thanks, looks like this does the trick: >> >> ./configure --with-freetype=/opt/X11 > > This came up a while back, probably on another list... > > XQuartz had to change the install location due to 10.11 not allowing installation to /usr/X11, so our configure script should be updated to also check in /opt/X11 now. I don't know if a bug was ever filed for this or not. > > To answer the earlier question: Yes, freetype is required for OpenJDK builds on Mac. Incidentally, I have the same version of XQuartz installed on 10.10.5 and it creates symlinks: /usr/X11 -> /opt/X11 /usr/X11R6 -> /opt/X11 but those symlinks cannot be created on 10.11 for the aforementioned reason. -DrD- From derek.white at oracle.com Tue Jan 19 22:13:14 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 19 Jan 2016 17:13:14 -0500 Subject: --with-devkit doesn't control nmake In-Reply-To: <56969CA4.506@oracle.com> References: <56903541.6080408@oracle.com> <56969CA4.506@oracle.com> Message-ID: <569EB4FA.7070800@oracle.com> On 1/13/16 1:51 PM, Erik Joelsson wrote: > For your build to pick up nmake from some other VS installation means > you must have that VS installation in your path. Normally, only the > devkit bin dirs will be in the path if you start with a clean > environment. We have simply not encountered that before, but it is > definitely a bug. However, the hotspot build-infra project is > currently rewriting the hotspot makefiles (see build-infra/jdk9 forest > if you are interested) and we are getting rid of nmake. This project > will go into JDK 9 in hopefully not too long a time. > > Unless this is causing actual trouble now, we in the build group will > be reluctant to spend time on fixing the issue. We would of course > welcome contributions from others if someone is willing to do the work. Unfortunately our devops group by default supplies an "entitlement" Windows VM with 3-4 VC++ toolchains on the path. But I think the option of removing nmake is the right way to go. It also takes care of the issue of how to specify customized make arguments to both the gmake and nmake programs we currently use. Thanks! - Derek > > /Erik > > On 2016-01-08 23:16, Derek White wrote: >> [This is likely a bug, but thought I'd ask it as a question first]. >> >> Windows devkits contain an nmake.exe, but the configure and make >> scripts do not define and consistently use an NMAKE variable to make >> sure the devkit version is used, as many other commands do. >> >> I had assumed that my builds were using the nmake.exe from the same >> devkit toolchain as the compilers, etc., but in fact I was using >> nmake from VS2005, as provided by my company's devops department on >> my entitlement machine. >> >> I don't believe that actually caused problems in my builds, but it >> took a while to confirm it, and could easily cause a problem in the >> future. >> >> Bug or no bug? Thanks! >> >> - Derek > From david.dehaven at oracle.com Tue Jan 19 22:40:22 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 19 Jan 2016 14:40:22 -0800 Subject: Configure(still?) broken on OS X In-Reply-To: <7D4506AF-6FBA-4622-9DF8-854846C5CB63@oracle.com> References: <569755E6.7060208@oracle.com> <5697B9B5.8020801@oracle.com> <7D4506AF-6FBA-4622-9DF8-854846C5CB63@oracle.com> Message-ID: <48A957F8-2F29-4AEE-85F0-824104A04ADA@oracle.com> >>> Thanks, looks like this does the trick: >>> >>> ./configure --with-freetype=/opt/X11 >> >> This came up a while back, probably on another list... >> >> XQuartz had to change the install location due to 10.11 not allowing installation to /usr/X11, so our configure script should be updated to also check in /opt/X11 now. I don't know if a bug was ever filed for this or not. >> >> To answer the earlier question: Yes, freetype is required for OpenJDK builds on Mac. > > Incidentally, I have the same version of XQuartz installed on 10.10.5 and it creates symlinks: > /usr/X11 -> /opt/X11 > /usr/X11R6 -> /opt/X11 > > but those symlinks cannot be created on 10.11 for the aforementioned reason. > > -DrD- > I filed an issue to fix this and provided a proposed fix, but I've not tested it at all (and I can't at the moment...) https://bugs.openjdk.java.net/browse/JDK-8147754 -DrD- From derek.white at oracle.com Tue Jan 19 22:55:58 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 19 Jan 2016 17:55:58 -0500 Subject: Is there any valid reason that a debug or fastdebug build should define PRODUCT and not ASSERT during compiles? In-Reply-To: <5697813D.2060105@oracle.com> References: <56903337.3080802@oracle.com> <5697813D.2060105@oracle.com> Message-ID: <569EBEFE.4060303@oracle.com> Hi Magnus, On 1/14/16 6:06 AM, Magnus Ihse Bursie wrote: > On 2016-01-08 23:07, Derek White wrote: >> [This is likely a bug, but thought I'd ask it as a question first]. >> >> I'm new to jdk builds on windows, and have spent way more time than >> I'd like to admit on figuring out why my fastdebug builds did not >> have asserts turned on. >> >> The TL;DR; answer is that anyone can build this way on Windows by >> simply executing this in cygwin before doing a make: >> > export release="Derek is having a fun day" >> > bash common/bin/jib.sh make -p windows-x86-debug -- images >> >> (This bug has nothing to do with jib, it's just the actual command >> line I used.) >> >> This results in a build with both /D "DEBUG_LEVEL=\"fastdebug\"" and >> /D "PRODUCT" set, because nmake.exe uppercases all environment >> variables as it imports them (as a convenience to the user). >> >> I'd think that there is no useful purpose to supporting such a >> configuration, and it's a bug to attempt it. I suggest doing an >> "!ifdef RELEASE" check in windows/makefiles/debug.make and >> windows/makefiles/fastdebug.make that either errors or unsets RELEASE >> before including vm.make. >> >> Any thoughts on this? Thanks! > > In general, environment variables can have unexpected effects on the > build, if they match a name used in the make files. There is no > general solution to this problem. > > As for this specific problem, as Erik said in a reply to your other > mail, we are currently working on replacing the use of nmake, so we > are not keen on spending time fixing issues in the current nmake scripts. > > Since this problem has existed since the dawn of time (or so...), and > it has not been reported until now, and given that there is a good > workaround, I don't consider it worth fixing. > > I appreciate that you spent time to figure out the issue and that you > reported it to us in such a polite manner! :-) I hope I don't come > across as rude by dismissing your suggested fix, it's just that I want > to spend all possible time on getting rid of nmake instead of fixing > issues in it. > > /Magnus Unfortunately I ended up modifying a unix .bashrc file provided by Sun IT back in the day to use in my cygwin env. For whatever reason Sun IT defined the variable "release" :-(. I am happy to see the nmake dependency go away. I'd like to make sure that the new windows make files don't depend unnecessarily on a RELEASE variable, but instead follow the linux/mac/solaris convention of having the top-level make files (product/fastdebug/debug) add in the correct options (ASSERT/PRODUCT, etc) as needed. - Derek From andreas.lundblad at oracle.com Wed Jan 20 04:40:46 2016 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 20 Jan 2016 05:40:46 +0100 Subject: RFR: JDK-8147449: sjavac builds of jdk9/dev with closed sources broken In-Reply-To: <569E3A3D.1010101@oracle.com> References: <569E106D.7030300@oracle.com> <569E3A3D.1010101@oracle.com> Message-ID: <20160120044046.GA3707@e6430> On Tue, Jan 19, 2016 at 02:29:33PM +0100, Magnus Ihse Bursie wrote: > On 2016-01-19 11:31, Erik Joelsson wrote: > >Hello, > > > >Please review this fix in the makefiles for using sjavac. The > >include/exclude mechanism in sjavac has changed. We used to > >sometimes exclude files using a full absolute path. This no longer > >works. The same thing can be achieved by splitting up the source > >roots argument to sjavac in separate -src arguments and then > >filter includes and excludes that are unique to a specific source > >root. Since this risks making command lines much longer, I also > >added a conditional ListPathsSafely/@file construct. > > > >Bug: https://bugs.openjdk.java.net/browse/JDK-8147449 > >Webrev: http://cr.openjdk.java.net/~erikj/8147449/webrev.01/ > > It's a bit head-ache-inducing (not your fault, though!) but it looks > correct to me. To summarize the discussion Erik and I had on this topic... Enabling absolute paths in the include/exclude patterns is a bit problematic unfortunately. The reason behind this is that sjavac would have to figure out if the absolute or relative path of a file sohuld be used in the include/exclude check. This decision would depend on whether the pattern is absolute or relative. Trying to pin down what an "absolute pattern" means is tricky though. To make a long story short, consider for example "{/home,foo}/bar". (Before the include/exclude rewrite we had -i, -if, -x and -xf to distinguish the cases. This was a mess. The wildcard had different semantics for the different switches for instance.) An alternavite route that I and Erik briefly discussed was to rely on explicit listing of the files instead, as we do for javac (and maybe even drop the include/exclude mechanism). This has a couple of pros'n'cons and is a subject of a larger discussion that I think we can have at a later point. -- Andreas From erik.joelsson at oracle.com Wed Jan 20 09:16:15 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Jan 2016 10:16:15 +0100 Subject: RFR: JDK-8147786: Building hotspot gives error message from find Message-ID: <569F505F.6070507@oracle.com> Due to a collision between two fixes (JDK-8146403 and JDK-8067194), whenever we build hotspot now we get the message: /usr/bin/find: `/localhome/hg/jdk9-dev-ALT/hotspot/agent': No such file or directory Bug: https://bugs.openjdk.java.net/browse/JDK-8147786 Patch: erik at pilot:/localhome/hg/jdk9-dev$ hg diff diff -r f382e4228537 make/HotspotWrapper.gmk --- a/make/HotspotWrapper.gmk +++ b/make/HotspotWrapper.gmk @@ -38,7 +38,7 @@ # Get all files in src, make or agent subdirs in hotspot directory and # filter out .hg. This skips the test directory. HOTSPOT_FILES := $(shell $(FIND) -L \ - $(HOTSPOT_TOPDIR)/src $(HOTSPOT_TOPDIR)/make $(HOTSPOT_TOPDIR)/agent \ + $(HOTSPOT_TOPDIR)/src $(HOTSPOT_TOPDIR)/make \ -name ".hg" -prune -o -print) # The old build creates hotspot output dir before calling hotspot and /Erik From sgehwolf at redhat.com Wed Jan 20 09:43:47 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 20 Jan 2016 10:43:47 +0100 Subject: javac server: No port file values materialized. on AIX In-Reply-To: References: <56975720.2010606@oracle.com> <20160114122303.GD14798@e6430> <20160117170810.GA26924@e6430> <569C95A5.50409@oracle.com> <20160118143441.GA13405@e6430> Message-ID: <1453283027.15872.6.camel@redhat.com> Hi, I'm doubtful this is an issue specific to AIX since I'm seing this now on a Linux box. See below. On Mon, 2016-01-18 at 15:39 +0100, Volker Simonis wrote: > On Mon, Jan 18, 2016 at 3:34 PM, Andreas Lundblad > wrote: > > > > > Interesting observation. The code for waiting for valid port file values > > > > > basically looks like > > > > > > > > > > ?????for (int i = 0; i < 10; i++) { > > > > > ?????????checkPortFile(); > > > > > ?????????if (successful) > > > > > ?????????????break; > > > > > ?????????sleep(500); > > > > > ?????} > > > > > > > > > > so the fact that it even reaches 6676 ms looks suspicious when it comes to > > > > > load. > > > > > > > > > > > > Why? Under load those sleep(500)'s might not return for much longer; and the > > > > whole things might be time preempted at any point for an extended period of > > > > time. > > > > What I meant was that the fact that the code takes 6676 ms to complete increases my suspicion about it being due to a load issue. FWIW, I'm seeing this issue now on the Zero builder: http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/203/console The builder might be under load which could cause this, but nevertheless it's the first time I'm seeing this. Has the above code been introduced recently? Is there a bug I can CC myself to? Thanks, Severin From magnus.ihse.bursie at oracle.com Wed Jan 20 10:54:42 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 20 Jan 2016 11:54:42 +0100 Subject: RFR: JDK-8147795 Build system support for BSD Message-ID: <569F6772.50703@oracle.com> During my spare time last autumn, and in the holidays, I've been playing around with the three major BSDs (FreeBSD, OpenBSD and NetBSD), trying to learn something new. (Yeah, I know, this proves that I have no life :-)). And what better way to learn an operating system than to try and build OpenJDK on it? :-) It quickly turned out that while there is a bsd-port/jdk9 forest, it is empty (that is, it's identical to jdk9/jdk9 with no BSD-specific patches in it). And building jdk8 is sooo 2014. :) So I started hacking around, focusing on improving issues in the build system that prevented the build to succeed. I also needed to fix issues in the source code (of course), but not as much as I'd expected. My total solution builds and runs (I've tested "javac HelloWorld.java") on the three BSDs, but some workarounds are needed, mostly likely due to incomplete fixes in the source code. The build changes turned out to also be an improvement for all platforms in some areas, and I'd like to integrate it into the mainline. While it is not enough in itself to build on BSD, it's a (necessary) step on the way. I'll post a second review later on for my source code changes, which still need some more cleanup to be presentable. Bug: https://bugs.openjdk.java.net/browse/JDK-8147795 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8147795-build-system-support-for-bsd/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Wed Jan 20 11:00:41 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 20 Jan 2016 12:00:41 +0100 Subject: RFR: JDK-8147786: Building hotspot gives error message from find In-Reply-To: <569F505F.6070507@oracle.com> References: <569F505F.6070507@oracle.com> Message-ID: <569F68D9.7020705@oracle.com> On 2016-01-20 10:16, Erik Joelsson wrote: > Due to a collision between two fixes (JDK-8146403 and JDK-8067194), > whenever we build hotspot now we get the message: > /usr/bin/find: `/localhome/hg/jdk9-dev-ALT/hotspot/agent': No such > file or directory > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147786 > Patch: > erik at pilot:/localhome/hg/jdk9-dev$ hg diff > diff -r f382e4228537 make/HotspotWrapper.gmk > --- a/make/HotspotWrapper.gmk > +++ b/make/HotspotWrapper.gmk > @@ -38,7 +38,7 @@ > # Get all files in src, make or agent subdirs in hotspot directory and > # filter out .hg. This skips the test directory. > HOTSPOT_FILES := $(shell $(FIND) -L \ > - $(HOTSPOT_TOPDIR)/src $(HOTSPOT_TOPDIR)/make > $(HOTSPOT_TOPDIR)/agent \ > + $(HOTSPOT_TOPDIR)/src $(HOTSPOT_TOPDIR)/make \ > -name ".hg" -prune -o -print) > > # The old build creates hotspot output dir before calling hotspot and Looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Wed Jan 20 11:02:56 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 20 Jan 2016 12:02:56 +0100 Subject: RFR: JDK-8147795 Build system support for BSD In-Reply-To: <569F6772.50703@oracle.com> References: <569F6772.50703@oracle.com> Message-ID: <569F6960.7060905@oracle.com> On 2016-01-20 11:54, Magnus Ihse Bursie wrote: > During my spare time last autumn, and in the holidays, I've been > playing around with the three major BSDs (FreeBSD, OpenBSD and > NetBSD), trying to learn something new. (Yeah, I know, this proves > that I have no life :-)). > > And what better way to learn an operating system than to try and build > OpenJDK on it? :-) It quickly turned out that while there is a > bsd-port/jdk9 forest, it is empty (that is, it's identical to > jdk9/jdk9 with no BSD-specific patches in it). And building jdk8 is > sooo 2014. :) > > So I started hacking around, focusing on improving issues in the build > system that prevented the build to succeed. I also needed to fix > issues in the source code (of course), but not as much as I'd > expected. My total solution builds and runs (I've tested "javac > HelloWorld.java") on the three BSDs, but some workarounds are needed, > mostly likely due to incomplete fixes in the source code. > > The build changes turned out to also be an improvement for all > platforms in some areas, and I'd like to integrate it into the > mainline. While it is not enough in itself to build on BSD, it's a > (necessary) step on the way. I'll post a second review later on for my > source code changes, which still need some more cleanup to be > presentable. However, if anyone is curious, here is my current patchset. Note that this is *not* part of the review for JDK-8147795 . http://cr.openjdk.java.net/~ihse/JDK-8147795_addendum-bsd-source-patches/webrev.01/ /Magnus > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147795 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8147795-build-system-support-for-bsd/webrev.01 > > /Magnus From Alan.Bateman at oracle.com Wed Jan 20 11:15:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Jan 2016 11:15:40 +0000 Subject: RFR: JDK-8147795 Build system support for BSD In-Reply-To: <569F6772.50703@oracle.com> References: <569F6772.50703@oracle.com> Message-ID: <569F6C5C.1020007@oracle.com> On 20/01/2016 10:54, Magnus Ihse Bursie wrote: > During my spare time last autumn, and in the holidays, I've been > playing around with the three major BSDs (FreeBSD, OpenBSD and > NetBSD), trying to learn something new. (Yeah, I know, this proves > that I have no life :-)). > > And what better way to learn an operating system than to try and build > OpenJDK on it? :-) It quickly turned out that while there is a > bsd-port/jdk9 forest, it is empty (that is, it's identical to > jdk9/jdk9 with no BSD-specific patches in it). And building jdk8 is > sooo 2014. :) > > So I started hacking around, focusing on improving issues in the build > system that prevented the build to succeed. I also needed to fix > issues in the source code (of course), but not as much as I'd > expected. My total solution builds and runs (I've tested "javac > HelloWorld.java") on the three BSDs, but some workarounds are needed, > mostly likely due to incomplete fixes in the source code. > > The build changes turned out to also be an improvement for all > platforms in some areas, and I'd like to integrate it into the > mainline. While it is not enough in itself to build on BSD, it's a > (necessary) step on the way. I'll post a second review later on for my > source code changes, which still need some more cleanup to be > presentable. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147795 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8147795-build-system-support-for-bsd/webrev.01 Clearly some good work here but who is going to maintain this? For the AIX port then the SAP engineers maintain the port and keeping it working, it's not clear what will happen here. Also support for new ports feels like it should have a JEP. Maybe I need to wait for the "source code webrev" but I could imagine some refactoring needed to avoid duplication with OS X specific code. Also when the Mac port was brought into OpenJDK then it came with a lot of #ifdef _ALLBSD_SOURCE patches and a lot of inconsistencies. General PITA when trying to move OS X specific patches forward and I know of several areas where the BSD specific code was just dropped. -Alan. From david.holmes at oracle.com Wed Jan 20 12:00:54 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jan 2016 22:00:54 +1000 Subject: javac server: No port file values materialized. on AIX In-Reply-To: <1453283027.15872.6.camel@redhat.com> References: <56975720.2010606@oracle.com> <20160114122303.GD14798@e6430> <20160117170810.GA26924@e6430> <569C95A5.50409@oracle.com> <20160118143441.GA13405@e6430> <1453283027.15872.6.camel@redhat.com> Message-ID: <569F76F6.5000205@oracle.com> On 20/01/2016 7:43 PM, Severin Gehwolf wrote: > Hi, > > I'm doubtful this is an issue specific to AIX since I'm seing this now > on a Linux box. See below. It isn't specific to AIX. As Erik said earlier in the thread we see this occasionally on Solaris too. David > > On Mon, 2016-01-18 at 15:39 +0100, Volker Simonis wrote: >> On Mon, Jan 18, 2016 at 3:34 PM, Andreas Lundblad >> wrote: >>>>>> Interesting observation. The code for waiting for valid port file values >>>>>> basically looks like >>>>>> >>>>>> for (int i = 0; i < 10; i++) { >>>>>> checkPortFile(); >>>>>> if (successful) >>>>>> break; >>>>>> sleep(500); >>>>>> } >>>>>> >>>>>> so the fact that it even reaches 6676 ms looks suspicious when it comes to >>>>>> load. >>>>> >>>>> >>>>> Why? Under load those sleep(500)'s might not return for much longer; and the >>>>> whole things might be time preempted at any point for an extended period of >>>>> time. >>> >>> What I meant was that the fact that the code takes 6676 ms to complete increases my suspicion about it being due to a load issue. > > FWIW, I'm seeing this issue now on the Zero builder: > http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/203/console > > The builder might be under load which could cause this, but > nevertheless it's the first time I'm seeing this. Has the above code > been introduced recently? > > Is there a bug I can CC myself to? > > Thanks, > Severin > From david.holmes at oracle.com Wed Jan 20 12:06:43 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jan 2016 22:06:43 +1000 Subject: RFR: JDK-8147795 Build system support for BSD In-Reply-To: <569F6C5C.1020007@oracle.com> References: <569F6772.50703@oracle.com> <569F6C5C.1020007@oracle.com> Message-ID: <569F7853.8070400@oracle.com> On 20/01/2016 9:15 PM, Alan Bateman wrote: > On 20/01/2016 10:54, Magnus Ihse Bursie wrote: >> During my spare time last autumn, and in the holidays, I've been >> playing around with the three major BSDs (FreeBSD, OpenBSD and >> NetBSD), trying to learn something new. (Yeah, I know, this proves >> that I have no life :-)). >> >> And what better way to learn an operating system than to try and build >> OpenJDK on it? :-) It quickly turned out that while there is a >> bsd-port/jdk9 forest, it is empty (that is, it's identical to >> jdk9/jdk9 with no BSD-specific patches in it). And building jdk8 is >> sooo 2014. :) >> >> So I started hacking around, focusing on improving issues in the build >> system that prevented the build to succeed. I also needed to fix >> issues in the source code (of course), but not as much as I'd >> expected. My total solution builds and runs (I've tested "javac >> HelloWorld.java") on the three BSDs, but some workarounds are needed, >> mostly likely due to incomplete fixes in the source code. >> >> The build changes turned out to also be an improvement for all >> platforms in some areas, and I'd like to integrate it into the >> mainline. While it is not enough in itself to build on BSD, it's a >> (necessary) step on the way. I'll post a second review later on for my >> source code changes, which still need some more cleanup to be >> presentable. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147795 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8147795-build-system-support-for-bsd/webrev.01 >> > > Clearly some good work here but who is going to maintain this? For the > AIX port then the SAP engineers maintain the port and keeping it > working, it's not clear what will happen here. Also support for new > ports feels like it should have a JEP. My thoughts exactly. I was under the impression that what we had for OSX already worked on some of the BSD's as we have had some patches in the past from people building on that platform. But an attempt to produce complete support for the various BSD's needs to come with some level of support and commitment. David ----- > Maybe I need to wait for the "source code webrev" but I could imagine > some refactoring needed to avoid duplication with OS X specific code. > Also when the Mac port was brought into OpenJDK then it came with a lot > of #ifdef _ALLBSD_SOURCE patches and a lot of inconsistencies. General > PITA when trying to move OS X specific patches forward and I know of > several areas where the BSD specific code was just dropped. > > -Alan. From andreas.lundblad at oracle.com Wed Jan 20 13:04:50 2016 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 20 Jan 2016 14:04:50 +0100 Subject: javac server: No port file values materialized. on AIX In-Reply-To: <1453283027.15872.6.camel@redhat.com> References: <56975720.2010606@oracle.com> <20160114122303.GD14798@e6430> <20160117170810.GA26924@e6430> <569C95A5.50409@oracle.com> <20160118143441.GA13405@e6430> <1453283027.15872.6.camel@redhat.com> Message-ID: <20160120130449.GB13461@e6430> On Wed, Jan 20, 2016 at 10:43:47AM +0100, Severin Gehwolf wrote: > Hi, > > I'm doubtful this is an issue specific to AIX since I'm seing this now > on a Linux box. See below. > > On Mon, 2016-01-18 at 15:39 +0100, Volker Simonis wrote: > > On Mon, Jan 18, 2016 at 3:34 PM, Andreas Lundblad > > wrote: > > > > > > Interesting observation. The code for waiting for valid port file values > > > > > > basically looks like > > > > > > > > > > > > ?????for (int i = 0; i < 10; i++) { > > > > > > ?????????checkPortFile(); > > > > > > ?????????if (successful) > > > > > > ?????????????break; > > > > > > ?????????sleep(500); > > > > > > ?????} > > > > > > > > > > > > so the fact that it even reaches 6676 ms looks suspicious when it comes to > > > > > > load. > > > > > > > > > > > > > > > Why? Under load those sleep(500)'s might not return for much longer; and the > > > > > whole things might be time preempted at any point for an extended period of > > > > > time. > > > > > > What I meant was that the fact that the code takes 6676 ms to complete increases my suspicion about it being due to a load issue. > > FWIW, I'm seeing this issue now on the Zero builder: > http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/203/console > > The builder might be under load which could cause this, but > nevertheless it's the first time I'm seeing this. Has the above code > been introduced recently? The code has been there for a while, but it has only been activated by default recently. > Is there a bug I can CC myself to? Yes: JDK-8145392 A patch which bumps the default from 5 seconds to 60 seconds is currently under review. -- Andreas From sgehwolf at redhat.com Wed Jan 20 13:37:41 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 20 Jan 2016 14:37:41 +0100 Subject: javac server: No port file values materialized. on AIX In-Reply-To: <20160120130449.GB13461@e6430> References: <56975720.2010606@oracle.com> <20160114122303.GD14798@e6430> <20160117170810.GA26924@e6430> <569C95A5.50409@oracle.com> <20160118143441.GA13405@e6430> <1453283027.15872.6.camel@redhat.com> <20160120130449.GB13461@e6430> Message-ID: <1453297061.15872.37.camel@redhat.com> On Wed, 2016-01-20 at 14:04 +0100, Andreas Lundblad wrote: > > > > FWIW, I'm seeing this issue now on the Zero builder: > > http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/203/console > > > > The builder might be under load which could cause this, but > > nevertheless it's the first time I'm seeing this. Has the above code > > been introduced recently? > ? > The code has been there for a while, but it has only been activated by default recently. > > > Is there a bug I can CC myself to? > > Yes: JDK-8145392 > > A patch which bumps the default from 5 seconds to 60 seconds is currently under review. OK, thanks. Cheers, Severin From swpalmer at gmail.com Wed Jan 20 18:18:13 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 20 Jan 2016 13:18:13 -0500 Subject: ServerImpl misplaced null check Message-ID: <43F4760D-748F-4556-B187-83D3B593A3C8@gmail.com> I was searching for a way to set TCP_NODELAY for an Endpoint using the default HTTP server and after finally tracking down the existence of the ?sun.net.httpserver.nodelay? system property I noticed what appears to be a mistake (though not a big one) in the source code. Look here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c3ecf996006a/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java#l377 Notice the null check on ?chan? is performed after it may have been dereferenced to set the TCP_NODELAY on the channel?s socket. If chan truly can be null at that point, the check needs to be move up a few lines. Regards, Scott From magnus.ihse.bursie at oracle.com Wed Jan 20 21:17:16 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 20 Jan 2016 22:17:16 +0100 Subject: RFR: JDK-8147795 Build system support for BSD In-Reply-To: <569F7853.8070400@oracle.com> References: <569F6772.50703@oracle.com> <569F6C5C.1020007@oracle.com> <569F7853.8070400@oracle.com> Message-ID: <569FF95C.8060907@oracle.com> On 2016-01-20 13:06, David Holmes wrote: > On 20/01/2016 9:15 PM, Alan Bateman wrote: >> On 20/01/2016 10:54, Magnus Ihse Bursie wrote: >>> During my spare time last autumn, and in the holidays, I've been >>> playing around with the three major BSDs (FreeBSD, OpenBSD and >>> NetBSD), trying to learn something new. (Yeah, I know, this proves >>> that I have no life :-)). >>> >>> And what better way to learn an operating system than to try and build >>> OpenJDK on it? :-) It quickly turned out that while there is a >>> bsd-port/jdk9 forest, it is empty (that is, it's identical to >>> jdk9/jdk9 with no BSD-specific patches in it). And building jdk8 is >>> sooo 2014. :) >>> >>> So I started hacking around, focusing on improving issues in the build >>> system that prevented the build to succeed. I also needed to fix >>> issues in the source code (of course), but not as much as I'd >>> expected. My total solution builds and runs (I've tested "javac >>> HelloWorld.java") on the three BSDs, but some workarounds are needed, >>> mostly likely due to incomplete fixes in the source code. >>> >>> The build changes turned out to also be an improvement for all >>> platforms in some areas, and I'd like to integrate it into the >>> mainline. While it is not enough in itself to build on BSD, it's a >>> (necessary) step on the way. I'll post a second review later on for my >>> source code changes, which still need some more cleanup to be >>> presentable. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147795 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8147795-build-system-support-for-bsd/webrev.01 >>> >>> >> >> Clearly some good work here but who is going to maintain this? For the >> AIX port then the SAP engineers maintain the port and keeping it >> working, it's not clear what will happen here. Also support for new >> ports feels like it should have a JEP. > > My thoughts exactly. I was under the impression that what we had for > OSX already worked on some of the BSD's as we have had some patches in > the past from people building on that platform. But an attempt to > produce complete support for the various BSD's needs to come with some > level of support and commitment. I think I need to elaborate a bit on my thinking here. First of all, I agree that adding full support for a complete new port would, at the very least, require a JEP. This is not what I intended with this change. A reflection, though: If the requirement for such a port is that a company provides continuous testing and support, then I believe it's unlikely that any BSD port will ever reach the mainline, due to the community based nature of the BSD projects. (I'll leave aside the question if that is a reasonable requirement.) We already have the BSD Port Project [1], sponsored by the Porters Group [2]. They maintain their own forests. For jdk8, the forest contains a number of patches for BSD. These have not been included upstream, for reasons I can only speculate in. For jdk9, as I wrote in my mail, the forest has been created but no BSD-specific patches has been submitted. From my cursory inspection, the source code changes in bsd-port/jdk8 could probably be moved to bsd-port/jdk9 with considerable less effort than the makefile changes. It is my general impression that developers working with porting is good at fixing C/C++ changes that relate to the target platform of their port, but considerably less so in working with the makefile changes that might be needed. (That's not just about porting; developers in general are often more fluent and comfortable working in C/C++ than in makefiles or shell scripts.) My idea was to provide a sane basis in the build system, on top of which it is easier to create a full port. Note that I'm not *introducing* BSD support in the OpenJDK build system. We already have that, but only partially. I'm just filling in the holes. Most of the changes in my patch relate to the configure script. The configure script is by it's very nature adapted to running in various environments, officially supported as well as other, common as well as rare. Much of the peculiarities of the BSDs from the configure scripts point of view, is not very different from e.g. the recent request to support freetype on OS X El Capitan. I assumed that a bening change to the build system that does not affect any existing platforms, and which provides a good foundation for bringing the bsd-port to jdk9, would be a bit of a no-brainer to integrate. Even if it would break later on due to lack of continous testing, it's often a task of an order of magnitute simpler to fix a previously working code (even in Makefiles, and even to developers that are not fluent in make), than to add the initial code. I've cc:ed the bsd-port mailing list in this discussion. Maybe someone from that group has anything to add? /Magnus [1] http://openjdk.java.net/projects/bsd-port/ [2] http://openjdk.java.net/groups/porters/ > > David > ----- > >> Maybe I need to wait for the "source code webrev" but I could imagine >> some refactoring needed to avoid duplication with OS X specific code. >> Also when the Mac port was brought into OpenJDK then it came with a lot >> of #ifdef _ALLBSD_SOURCE patches and a lot of inconsistencies. General >> PITA when trying to move OS X specific patches forward and I know of >> several areas where the BSD specific code was just dropped. >> >> -Alan. From david.holmes at oracle.com Thu Jan 21 08:59:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Jan 2016 18:59:14 +1000 Subject: ServerImpl misplaced null check In-Reply-To: <43F4760D-748F-4556-B187-83D3B593A3C8@gmail.com> References: <43F4760D-748F-4556-B187-83D3B593A3C8@gmail.com> Message-ID: <56A09DE2.7070603@oracle.com> Hi Scott, cc'ing net-dev as this is not a build issue. David On 21/01/2016 4:18 AM, Scott Palmer wrote: > I was searching for a way to set TCP_NODELAY for an Endpoint using the default HTTP server and after finally tracking down the existence of the ?sun.net.httpserver.nodelay? system property I noticed what appears to be a mistake (though not a big one) in the source code. > > Look here: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c3ecf996006a/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java#l377 > > Notice the null check on ?chan? is performed after it may have been dereferenced to set the TCP_NODELAY on the channel?s socket. If chan truly can be null at that point, the check needs to be move up a few lines. > > Regards, > > Scott > From magnus.ihse.bursie at oracle.com Thu Jan 21 09:24:53 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 21 Jan 2016 10:24:53 +0100 Subject: Configure(still?) broken on OS X In-Reply-To: <48A957F8-2F29-4AEE-85F0-824104A04ADA@oracle.com> References: <569755E6.7060208@oracle.com> <5697B9B5.8020801@oracle.com> <7D4506AF-6FBA-4622-9DF8-854846C5CB63@oracle.com> <48A957F8-2F29-4AEE-85F0-824104A04ADA@oracle.com> Message-ID: <56A0A3E5.7040700@oracle.com> On 2016-01-19 23:40, David DeHaven wrote: >>>> Thanks, looks like this does the trick: >>>> >>>> ./configure --with-freetype=/opt/X11 >>> This came up a while back, probably on another list... >>> >>> XQuartz had to change the install location due to 10.11 not allowing installation to /usr/X11, so our configure script should be updated to also check in /opt/X11 now. I don't know if a bug was ever filed for this or not. >>> >>> To answer the earlier question: Yes, freetype is required for OpenJDK builds on Mac. >> Incidentally, I have the same version of XQuartz installed on 10.10.5 and it creates symlinks: >> /usr/X11 -> /opt/X11 >> /usr/X11R6 -> /opt/X11 >> >> but those symlinks cannot be created on 10.11 for the aforementioned reason. >> >> -DrD- >> > I filed an issue to fix this and provided a proposed fix, but I've not tested it at all (and I can't at the moment...) > https://bugs.openjdk.java.net/browse/JDK-8147754 I think we can be reasonably sure that if --with-freetype=/opt/X11 works, then your fix is working. I think your fix looks okay (apart from indentation but that might be Jira messing), but for formalitys sake I'd like you to send out a formal RFR. You don't need to create a webrev, the patch inline is ok. /Magnus From thomas.stuefe at gmail.com Thu Jan 21 10:06:58 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 21 Jan 2016 11:06:58 +0100 Subject: RFR: JDK-8147795 Build system support for BSD In-Reply-To: <569F6960.7060905@oracle.com> References: <569F6772.50703@oracle.com> <569F6960.7060905@oracle.com> Message-ID: Hi Magnus, for what it is worth, I like your effort and think this is valuable. Looking through your changes, it looks like the current BSD support (non-apply) is broken in a number of places and I think if we keep it, we should fix it. Disclaimer: I am neither a "R"eviewer nor a BSD expert. Because I am a typical programmer, I looked at your C/C++ changes rather than the makefile changes :) I understand they are not part of your review, and I was not sure if you wanted feedback, but nevertheless here are some notes/questions: --- http://cr.openjdk.java.net/~ihse/JDK-8147795_addendum-bsd-source-patches/webrev.01/hotspot/src/os/bsd/vm/jsig.c.frames.html About jvmsig_t (also applies to os_bsd.cpp): I do not understand why we do not use standard POSIX sigset_t to represend signal sets. But I understand that this is not in the scope of your change. --- http://cr.openjdk.java.net/~ihse/JDK-8147795_addendum-bsd-source-patches/webrev.01/hotspot/src/os/posix/vm/os_posix.cpp.frames.html print_rlimit_info(): would it make not more sense to just print both "AS" and "DATA" on all platforms? --- http://cr.openjdk.java.net/~ihse/JDK-8147795_addendum-bsd-source-patches/webrev.01/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c.frames.html I am confused about the "waitid on Mac OS X 10.7 seems to be broken;"; if this is still an issue, would it not make sense to use your alternate path (using waitpid() instead) for MacOS too? --- http://cr.openjdk.java.net/~ihse/JDK-8147795_addendum-bsd-source-patches/webrev.01/jdk/src/java.base/unix/native/libnet/portconfig.c.frames.html Should your approach (using sysctl() instead of sysctlbyname) not work on all BSD variants? Could the __OpenBSD__ and the _ALLBSD_SOURCE_ branch folded into one? Kind Regards, Thomas On Wed, Jan 20, 2016 at 12:02 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2016-01-20 11:54, Magnus Ihse Bursie wrote: > >> During my spare time last autumn, and in the holidays, I've been playing >> around with the three major BSDs (FreeBSD, OpenBSD and NetBSD), trying to >> learn something new. (Yeah, I know, this proves that I have no life :-)). >> >> And what better way to learn an operating system than to try and build >> OpenJDK on it? :-) It quickly turned out that while there is a >> bsd-port/jdk9 forest, it is empty (that is, it's identical to jdk9/jdk9 >> with no BSD-specific patches in it). And building jdk8 is sooo 2014. :) >> >> So I started hacking around, focusing on improving issues in the build >> system that prevented the build to succeed. I also needed to fix issues in >> the source code (of course), but not as much as I'd expected. My total >> solution builds and runs (I've tested "javac HelloWorld.java") on the three >> BSDs, but some workarounds are needed, mostly likely due to incomplete >> fixes in the source code. >> >> The build changes turned out to also be an improvement for all platforms >> in some areas, and I'd like to integrate it into the mainline. While it is >> not enough in itself to build on BSD, it's a (necessary) step on the way. >> I'll post a second review later on for my source code changes, which still >> need some more cleanup to be presentable. >> > > However, if anyone is curious, here is my current patchset. Note that this > is *not* part of the review for JDK-8147795 . > > > http://cr.openjdk.java.net/~ihse/JDK-8147795_addendum-bsd-source-patches/webrev.01/ > > /Magnus > > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147795 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8147795-build-system-support-for-bsd/webrev.01 >> >> /Magnus >> > > > From erik.joelsson at oracle.com Thu Jan 21 10:19:39 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 Jan 2016 11:19:39 +0100 Subject: RFR: JDK-8147930: Langtools test Makefile still requires special make in Cygwin Message-ID: <56A0B0BB.8020904@oracle.com> The langtools test Makefile doesn't work in Cygwin with the default make. It still expects the specially built gnu make which handles ':' in path names and particularly in rule declarations. The cause of the failure is JCK_HOME, which on Windows defaults to a string starting with "J:/". Bug: https://bugs.openjdk.java.net/browse/JDK-8147930 Patch: diff -r 1fd828240c4d test/Makefile --- a/test/Makefile +++ b/test/Makefile @@ -412,7 +412,15 @@ fi # Check to make sure these directories exist -check-jck: $(JCK_HOME) $(PRODUCT_HOME) +check-jck: + if [ ! -d '$(JCK_HOME)' ]; then \ + echo "JCK_HOME $(JCK_HOME) missing" ; \ + $(EXIT) 1 ; \ + fi + if [ ! -d '$(PRODUCT_HOME)' ]; then \ + echo "PRODUCT_HOME $(PRODUCT_HOME) missing" ; \ + $(EXIT) 1 ; \ + fi all-summary: FRC @if [ -n "`find $(TEST_OUTPUT_DIR) -name status.txt`" ]; then /Erik From magnus.ihse.bursie at oracle.com Thu Jan 21 10:44:35 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 21 Jan 2016 11:44:35 +0100 Subject: RFR: JDK-8147930: Langtools test Makefile still requires special make in Cygwin In-Reply-To: <56A0B0BB.8020904@oracle.com> References: <56A0B0BB.8020904@oracle.com> Message-ID: <56A0B693.3070801@oracle.com> On 2016-01-21 11:19, Erik Joelsson wrote: > The langtools test Makefile doesn't work in Cygwin with the default > make. It still expects the specially built gnu make which handles ':' > in path names and particularly in rule declarations. > > The cause of the failure is JCK_HOME, which on Windows defaults to a > string starting with "J:/". > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147930 > Patch: > diff -r 1fd828240c4d test/Makefile > --- a/test/Makefile > +++ b/test/Makefile > @@ -412,7 +412,15 @@ > fi > > # Check to make sure these directories exist > -check-jck: $(JCK_HOME) $(PRODUCT_HOME) > +check-jck: > + if [ ! -d '$(JCK_HOME)' ]; then \ > + echo "JCK_HOME $(JCK_HOME) missing" ; \ > + $(EXIT) 1 ; \ > + fi > + if [ ! -d '$(PRODUCT_HOME)' ]; then \ > + echo "PRODUCT_HOME $(PRODUCT_HOME) missing" ; \ > + $(EXIT) 1 ; \ > + fi > > all-summary: FRC > @if [ -n "`find $(TEST_OUTPUT_DIR) -name status.txt`" ]; then Looks good to me. Messy thing, those windows paths. :( /Magnus > > > /Erik From erik.joelsson at oracle.com Thu Jan 21 10:45:52 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 Jan 2016 11:45:52 +0100 Subject: RFR: JDK-8147933: Configure check for number of cpus ignores HT on Macosx Message-ID: <56A0B6E0.8090305@oracle.com> On all other platforms except Macosx, the logic for detecting number of cpus includes hyperthreading in their count. We do see some speedup from setting the make -j flag to a number that includes HT so we should do the same on macosx. I chose to fix this by querying sysctl for hardware information. It also seems to much simpler so I changed the memory detecting logic to use the same technique. Bug: https://bugs.openjdk.java.net/browse/JDK-8147933 Patch: diff -r f36cf7e8ba68 common/autoconf/build-performance.m4 --- a/common/autoconf/build-performance.m4 +++ b/common/autoconf/build-performance.m4 @@ -39,7 +39,7 @@ FOUND_CORES=yes elif test -x /usr/sbin/system_profiler; then # Looks like a MacOSX system - NUM_CORES=`/usr/sbin/system_profiler -detailLevel full SPHardwareDataType | grep 'Cores' | awk '{print [$]5}'` + NUM_CORES=`/usr/sbin/sysctl -n hw.ncpu` FOUND_CORES=yes elif test "x$OPENJDK_BUILD_OS" = xaix ; then NUM_CORES=`/usr/sbin/prtconf | grep "^Number Of Processors" | awk '{ print [$]4 }'` @@ -76,8 +76,8 @@ FOUND_MEM=yes elif test -x /usr/sbin/system_profiler; then # Looks like a MacOSX system - MEMORY_SIZE=`/usr/sbin/system_profiler -detailLevel full SPHardwareDataType | grep 'Memory' | awk '{print [$]2}'` - MEMORY_SIZE=`expr $MEMORY_SIZE \* 1024` + MEMORY_SIZE=`/usr/sbin/sysctl -n hw.memsize` + MEMORY_SIZE=`expr $MEMORY_SIZE / 1024 / 1024` FOUND_MEM=yes elif test "x$OPENJDK_BUILD_OS" = xwindows; then # Windows, but without cygwin /Erik From erik.joelsson at oracle.com Thu Jan 21 10:52:24 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 Jan 2016 11:52:24 +0100 Subject: RFR: JDK-8147934: Remove --with-sdk-name from macosx jib profile Message-ID: <56A0B868.9090308@oracle.com> The --with-sdk-name in the macosx profile is not needed, and will be ignored. Configure complains: WARNING: Both SYSROOT and --with-sdk-name are set, only SYSROOT will be used The devkit already enforces the correct sdk name through setting sysroot. Bug: https://bugs.openjdk.java.net/browse/JDK-8147934 Patch: diff -r f36cf7e8ba68 common/conf/jib-profiles.js --- a/common/conf/jib-profiles.js +++ b/common/conf/jib-profiles.js @@ -257,7 +257,7 @@ target_os: "macosx", target_cpu: "x64", dependencies: concat(common.dependencies, "devkit"), - configure_args: concat(common.configure_args, "--with-sdk-name=macosx10.9"), + configure_args: common.configure_args, make_args: common.make_args }, /Erik From magnus.ihse.bursie at oracle.com Thu Jan 21 11:06:44 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 21 Jan 2016 12:06:44 +0100 Subject: RFR: JDK-8147933: Configure check for number of cpus ignores HT on Macosx In-Reply-To: <56A0B6E0.8090305@oracle.com> References: <56A0B6E0.8090305@oracle.com> Message-ID: <56A0BBC4.7050807@oracle.com> On 2016-01-21 11:45, Erik Joelsson wrote: > On all other platforms except Macosx, the logic for detecting number > of cpus includes hyperthreading in their count. We do see some speedup > from setting the make -j flag to a number that includes HT so we > should do the same on macosx. > > I chose to fix this by querying sysctl for hardware information. It > also seems to much simpler so I changed the memory detecting logic to > use the same technique. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147933 > Patch: > diff -r f36cf7e8ba68 common/autoconf/build-performance.m4 > --- a/common/autoconf/build-performance.m4 > +++ b/common/autoconf/build-performance.m4 > @@ -39,7 +39,7 @@ > FOUND_CORES=yes > elif test -x /usr/sbin/system_profiler; then > # Looks like a MacOSX system > - NUM_CORES=`/usr/sbin/system_profiler -detailLevel full > SPHardwareDataType | grep 'Cores' | awk '{print [$]5}'` > + NUM_CORES=`/usr/sbin/sysctl -n hw.ncpu` > FOUND_CORES=yes > elif test "x$OPENJDK_BUILD_OS" = xaix ; then > NUM_CORES=`/usr/sbin/prtconf | grep "^Number Of Processors" | awk > '{ print [$]4 }'` > @@ -76,8 +76,8 @@ > FOUND_MEM=yes > elif test -x /usr/sbin/system_profiler; then > # Looks like a MacOSX system > - MEMORY_SIZE=`/usr/sbin/system_profiler -detailLevel full > SPHardwareDataType | grep 'Memory' | awk '{print [$]2}'` > - MEMORY_SIZE=`expr $MEMORY_SIZE \* 1024` > + MEMORY_SIZE=`/usr/sbin/sysctl -n hw.memsize` > + MEMORY_SIZE=`expr $MEMORY_SIZE / 1024 / 1024` > FOUND_MEM=yes > elif test "x$OPENJDK_BUILD_OS" = xwindows; then > # Windows, but without cygwin > Nice try but you also need to change theif test -x to /usr/sbin/sysctl instead of /usr/sbin/system_profiler ;-) /Magnus From magnus.ihse.bursie at oracle.com Thu Jan 21 11:07:03 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 21 Jan 2016 12:07:03 +0100 Subject: RFR: JDK-8147934: Remove --with-sdk-name from macosx jib profile In-Reply-To: <56A0B868.9090308@oracle.com> References: <56A0B868.9090308@oracle.com> Message-ID: <56A0BBD7.1080609@oracle.com> On 2016-01-21 11:52, Erik Joelsson wrote: > The --with-sdk-name in the macosx profile is not needed, and will be > ignored. Configure complains: > > WARNING: Both SYSROOT and --with-sdk-name are set, only SYSROOT will > be used > > The devkit already enforces the correct sdk name through setting sysroot. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147934 > Patch: > diff -r f36cf7e8ba68 common/conf/jib-profiles.js > --- a/common/conf/jib-profiles.js > +++ b/common/conf/jib-profiles.js > @@ -257,7 +257,7 @@ > target_os: "macosx", > target_cpu: "x64", > dependencies: concat(common.dependencies, "devkit"), > - configure_args: concat(common.configure_args, > "--with-sdk-name=macosx10.9"), > + configure_args: common.configure_args, > make_args: common.make_args > }, > Looks good to me. /Magnus From erik.joelsson at oracle.com Thu Jan 21 11:11:22 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 Jan 2016 12:11:22 +0100 Subject: RFR: JDK-8147933: Configure check for number of cpus ignores HT on Macosx In-Reply-To: <56A0BBC4.7050807@oracle.com> References: <56A0B6E0.8090305@oracle.com> <56A0BBC4.7050807@oracle.com> Message-ID: <56A0BCDA.9020000@oracle.com> Oops, too fast. diff -r f36cf7e8ba68 common/autoconf/build-performance.m4 --- a/common/autoconf/build-performance.m4 +++ b/common/autoconf/build-performance.m4 @@ -37,9 +37,9 @@ # Looks like a Solaris system NUM_CORES=`LC_MESSAGES=C /usr/sbin/psrinfo -v | grep -c on-line` FOUND_CORES=yes - elif test -x /usr/sbin/system_profiler; then + elif test -x /usr/sbin/sysctl; then # Looks like a MacOSX system - NUM_CORES=`/usr/sbin/system_profiler -detailLevel full SPHardwareDataType | grep 'Cores' | awk '{print [$]5}'` + NUM_CORES=`/usr/sbin/sysctl -n hw.ncpu` FOUND_CORES=yes elif test "x$OPENJDK_BUILD_OS" = xaix ; then NUM_CORES=`/usr/sbin/prtconf | grep "^Number Of Processors" | awk '{ print [$]4 }'` @@ -74,10 +74,10 @@ # Looks like a Solaris or AIX system MEMORY_SIZE=`/usr/sbin/prtconf | grep "^Memory [[Ss]]ize" | awk '{ print [$]3 }'` FOUND_MEM=yes - elif test -x /usr/sbin/system_profiler; then + elif test -x /usr/sbin/sysctl; then # Looks like a MacOSX system - MEMORY_SIZE=`/usr/sbin/system_profiler -detailLevel full SPHardwareDataType | grep 'Memory' | awk '{print [$]2}'` - MEMORY_SIZE=`expr $MEMORY_SIZE \* 1024` + MEMORY_SIZE=`/usr/sbin/sysctl -n hw.memsize` + MEMORY_SIZE=`expr $MEMORY_SIZE / 1024 / 1024` FOUND_MEM=yes elif test "x$OPENJDK_BUILD_OS" = xwindows; then # Windows, but without cygwin /Erik On 2016-01-21 12:06, Magnus Ihse Bursie wrote: > On 2016-01-21 11:45, Erik Joelsson wrote: >> On all other platforms except Macosx, the logic for detecting number >> of cpus includes hyperthreading in their count. We do see some >> speedup from setting the make -j flag to a number that includes HT so >> we should do the same on macosx. >> >> I chose to fix this by querying sysctl for hardware information. It >> also seems to much simpler so I changed the memory detecting logic to >> use the same technique. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147933 >> Patch: >> diff -r f36cf7e8ba68 common/autoconf/build-performance.m4 >> --- a/common/autoconf/build-performance.m4 >> +++ b/common/autoconf/build-performance.m4 >> @@ -39,7 +39,7 @@ >> FOUND_CORES=yes >> elif test -x /usr/sbin/system_profiler; then >> # Looks like a MacOSX system >> - NUM_CORES=`/usr/sbin/system_profiler -detailLevel full >> SPHardwareDataType | grep 'Cores' | awk '{print [$]5}'` >> + NUM_CORES=`/usr/sbin/sysctl -n hw.ncpu` >> FOUND_CORES=yes >> elif test "x$OPENJDK_BUILD_OS" = xaix ; then >> NUM_CORES=`/usr/sbin/prtconf | grep "^Number Of Processors" | >> awk '{ print [$]4 }'` >> @@ -76,8 +76,8 @@ >> FOUND_MEM=yes >> elif test -x /usr/sbin/system_profiler; then >> # Looks like a MacOSX system >> - MEMORY_SIZE=`/usr/sbin/system_profiler -detailLevel full >> SPHardwareDataType | grep 'Memory' | awk '{print [$]2}'` >> - MEMORY_SIZE=`expr $MEMORY_SIZE \* 1024` >> + MEMORY_SIZE=`/usr/sbin/sysctl -n hw.memsize` >> + MEMORY_SIZE=`expr $MEMORY_SIZE / 1024 / 1024` >> FOUND_MEM=yes >> elif test "x$OPENJDK_BUILD_OS" = xwindows; then >> # Windows, but without cygwin >> > Nice try but you also need to change theif test -x to /usr/sbin/sysctl > instead of /usr/sbin/system_profiler ;-) > > /Magnus > From magnus.ihse.bursie at oracle.com Thu Jan 21 11:19:52 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 21 Jan 2016 12:19:52 +0100 Subject: RFR: JDK-8147933: Configure check for number of cpus ignores HT on Macosx In-Reply-To: <56A0BCDA.9020000@oracle.com> References: <56A0B6E0.8090305@oracle.com> <56A0BBC4.7050807@oracle.com> <56A0BCDA.9020000@oracle.com> Message-ID: <56A0BED8.5050601@oracle.com> On 2016-01-21 12:11, Erik Joelsson wrote: > Oops, too fast. That's better. :-) LGTM. /Magnus > > diff -r f36cf7e8ba68 common/autoconf/build-performance.m4 > --- a/common/autoconf/build-performance.m4 > +++ b/common/autoconf/build-performance.m4 > @@ -37,9 +37,9 @@ > # Looks like a Solaris system > NUM_CORES=`LC_MESSAGES=C /usr/sbin/psrinfo -v | grep -c on-line` > FOUND_CORES=yes > - elif test -x /usr/sbin/system_profiler; then > + elif test -x /usr/sbin/sysctl; then > # Looks like a MacOSX system > - NUM_CORES=`/usr/sbin/system_profiler -detailLevel full > SPHardwareDataType | grep 'Cores' | awk '{print [$]5}'` > + NUM_CORES=`/usr/sbin/sysctl -n hw.ncpu` > FOUND_CORES=yes > elif test "x$OPENJDK_BUILD_OS" = xaix ; then > NUM_CORES=`/usr/sbin/prtconf | grep "^Number Of Processors" | awk > '{ print [$]4 }'` > @@ -74,10 +74,10 @@ > # Looks like a Solaris or AIX system > MEMORY_SIZE=`/usr/sbin/prtconf | grep "^Memory [[Ss]]ize" | awk > '{ print [$]3 }'` > FOUND_MEM=yes > - elif test -x /usr/sbin/system_profiler; then > + elif test -x /usr/sbin/sysctl; then > # Looks like a MacOSX system > - MEMORY_SIZE=`/usr/sbin/system_profiler -detailLevel full > SPHardwareDataType | grep 'Memory' | awk '{print [$]2}'` > - MEMORY_SIZE=`expr $MEMORY_SIZE \* 1024` > + MEMORY_SIZE=`/usr/sbin/sysctl -n hw.memsize` > + MEMORY_SIZE=`expr $MEMORY_SIZE / 1024 / 1024` > FOUND_MEM=yes > elif test "x$OPENJDK_BUILD_OS" = xwindows; then > # Windows, but without cygwin > > /Erik > > On 2016-01-21 12:06, Magnus Ihse Bursie wrote: >> On 2016-01-21 11:45, Erik Joelsson wrote: >>> On all other platforms except Macosx, the logic for detecting number >>> of cpus includes hyperthreading in their count. We do see some >>> speedup from setting the make -j flag to a number that includes HT >>> so we should do the same on macosx. >>> >>> I chose to fix this by querying sysctl for hardware information. It >>> also seems to much simpler so I changed the memory detecting logic >>> to use the same technique. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147933 >>> Patch: >>> diff -r f36cf7e8ba68 common/autoconf/build-performance.m4 >>> --- a/common/autoconf/build-performance.m4 >>> +++ b/common/autoconf/build-performance.m4 >>> @@ -39,7 +39,7 @@ >>> FOUND_CORES=yes >>> elif test -x /usr/sbin/system_profiler; then >>> # Looks like a MacOSX system >>> - NUM_CORES=`/usr/sbin/system_profiler -detailLevel full >>> SPHardwareDataType | grep 'Cores' | awk '{print [$]5}'` >>> + NUM_CORES=`/usr/sbin/sysctl -n hw.ncpu` >>> FOUND_CORES=yes >>> elif test "x$OPENJDK_BUILD_OS" = xaix ; then >>> NUM_CORES=`/usr/sbin/prtconf | grep "^Number Of Processors" | >>> awk '{ print [$]4 }'` >>> @@ -76,8 +76,8 @@ >>> FOUND_MEM=yes >>> elif test -x /usr/sbin/system_profiler; then >>> # Looks like a MacOSX system >>> - MEMORY_SIZE=`/usr/sbin/system_profiler -detailLevel full >>> SPHardwareDataType | grep 'Memory' | awk '{print [$]2}'` >>> - MEMORY_SIZE=`expr $MEMORY_SIZE \* 1024` >>> + MEMORY_SIZE=`/usr/sbin/sysctl -n hw.memsize` >>> + MEMORY_SIZE=`expr $MEMORY_SIZE / 1024 / 1024` >>> FOUND_MEM=yes >>> elif test "x$OPENJDK_BUILD_OS" = xwindows; then >>> # Windows, but without cygwin >>> >> Nice try but you also need to change theif test -x to >> /usr/sbin/sysctl instead of /usr/sbin/system_profiler ;-) >> >> /Magnus >> > From dalibor.topic at oracle.com Thu Jan 21 12:44:40 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 21 Jan 2016 13:44:40 +0100 Subject: RFR: JDK-8147795 Build system support for BSD In-Reply-To: <569FF95C.8060907@oracle.com> References: <569F6772.50703@oracle.com> <569F6C5C.1020007@oracle.com> <569F7853.8070400@oracle.com> <569FF95C.8060907@oracle.com> Message-ID: <56A0D2B8.2040004@oracle.com> On 20.01.2016 22:17, Magnus Ihse Bursie wrote: > A reflection, though: If the requirement for such a > port is that a company provides continuous testing and support, then I > believe it's unlikely that any BSD port will ever reach the mainline, > due to the community based nature of the BSD projects. Community supported ports have been merged into mainline in the past when they have passed the TCK with the expectation that they are kept in shape by the corresponding (sub)community in OpenJDK, and if they aren't, that they'd get dropped out of mainline again. A JEP would be a second item to look at, of course, now that we have a JEP process in place. Typically, they'd go through the JDK Release Project in development first (i.e. JDK 9 now), and then potentially get backported to an Update release Project. With respect to the BSD Port, the FreeBSD Foundation is listed here: http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html but I'm not sure if they have completed their respective efforts yet. > We already have the BSD Port Project [1], sponsored by the Porters Group > [2]. They maintain their own forests. For jdk8, the forest contains a > number of patches for BSD. These have not been included upstream, for > reasons I can only speculate in. I think it unfortunately came down to lack of man power among BSD Port developers at the time when the dust after the OS X Port's integration into JDK 8 settled. [1] Making it easier for the BSD port to integrate JDK 9 changes sounds fine to me, but I'm not a JDK 9/build area Reviewer. cheers, dalibor topic [1] http://mail.openjdk.java.net/pipermail/bsd-port-dev/2014-April/002245.html -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From erik.joelsson at oracle.com Thu Jan 21 14:42:27 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 Jan 2016 15:42:27 +0100 Subject: RFR: JDK-8147950: Change JPRT to use new platforms for Linux, Windows and Macosx Message-ID: <56A0EE53.4020305@oracle.com> We changed official build platforms a while back, but we still haven't completely changed what we use in JPRT. We are not quite ready to stop using the old build platforms yet. I would like to make a change to jprt.properties that enables us to use both for a time. Bug: https://bugs.openjdk.java.net/browse/JDK-8147950 Webrev: http://cr.openjdk.java.net/~erikj/8147950/webrev.01/ /Erik From tim.bell at oracle.com Thu Jan 21 15:52:14 2016 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 21 Jan 2016 07:52:14 -0800 Subject: RFR: JDK-8147950: Change JPRT to use new platforms for Linux, Windows and Macosx In-Reply-To: <56A0EE53.4020305@oracle.com> References: <56A0EE53.4020305@oracle.com> Message-ID: <56A0FEAE.9070205@oracle.com> Erik: > We changed official build platforms a while back, but we still haven't > completely changed what we use in JPRT. We are not quite ready to stop > using the old build platforms yet. I would like to make a change to > jprt.properties that enables us to use both for a time. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147950 > Webrev: http://cr.openjdk.java.net/~erikj/8147950/webrev.01 Looks good to me. Tim From mikael.vidstedt at oracle.com Thu Jan 21 21:39:57 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 21 Jan 2016 13:39:57 -0800 Subject: RFR: JDK-8147950: Change JPRT to use new platforms for Linux, Windows and Macosx In-Reply-To: <56A0EE53.4020305@oracle.com> References: <56A0EE53.4020305@oracle.com> Message-ID: <56A1502D.7080209@oracle.com> Looks good. Cheers, Mikael On 2016-01-21 06:42, Erik Joelsson wrote: > We changed official build platforms a while back, but we still haven't > completely changed what we use in JPRT. We are not quite ready to stop > using the old build platforms yet. I would like to make a change to > jprt.properties that enables us to use both for a time. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147950 > Webrev: http://cr.openjdk.java.net/~erikj/8147950/webrev.01/ > > /Erik From jvanek at redhat.com Fri Jan 22 12:44:07 2016 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 22 Jan 2016 13:44:07 +0100 Subject: [rfc] Avoid failure when compiler is wrapped. Message-ID: <56A22417.4080008@redhat.com> Hello! When compiler is wrapped, the configure phase of build fails: [...] checking for gcc... /usr/lib64/cscppc/gcc configure: Resolving CC (as /usr/lib64/cscppc/gcc) failed, using /usr/lib64/cscppc/gcc directly. checking resolved symbolic links for CC... /usr/bin/cscppc checking if CC is disguised ccache... no, keeping CC configure: The C compiler (located as /usr/bin/cscppc) does not seem to be the required GCC compiler. configure: The result from running with --version was: "Usage:" configure: error: GCC compiler is required. Try setting --with-tools-dir. configure exiting with result code 1 From time to time I'm building RPMS for fedora with wrapped compiler to be able to investigate C code changes. Added is patch, which is allowing to walk around the issue. I'm wondering if this is still desired behaviour. or if it can be better iff-ed out to be by default on, but eg only disablef on AIX. CCed is Andrew, who is facing similar issue on Gentoo. Thanx! J. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-autoconf-do-not-resolve-symbolic-links-in-CC.patch Type: text/x-patch Size: 969 bytes Desc: not available URL: From kumar.x.srinivasan at oracle.com Fri Jan 22 22:50:30 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 22 Jan 2016 14:50:30 -0800 Subject: 8035473: [javadoc] Revamp the existing Doclet APIs Message-ID: <56A2B236.7060001@oracle.com> Hi All, Please review the following build changes: JDK changes: * simple entry point change http://cr.openjdk.java.net/~ksrini/8035473/webrev.07/webrev.jdk.0/ Top forest repo: * configuration changes to use the new javadoc/doclet implementation * module dependency changes (*Mandy, Alan*) http://cr.openjdk.java.net/~ksrini/8035473/webrev.07/webrev.jdk9.0/ Langtools changes: * please review the build portions, ie. make/CompileInterim.gmk make/gensrc/Gensrc-jdk.javadoc.gmk make/netbeans/langtools/build.xml * core javadoc changes are reviewed by Jan, Jon, Bhavesh, Oleg, Vicente http://cr.openjdk.java.net/~ksrini/8035473/webrev.07/webrev.langtools.0/ Thanks Kumar From mandy.chung at oracle.com Fri Jan 22 23:13:26 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 Jan 2016 15:13:26 -0800 Subject: 8035473: [javadoc] Revamp the existing Doclet APIs In-Reply-To: <56A2B236.7060001@oracle.com> References: <56A2B236.7060001@oracle.com> Message-ID: > On Jan 22, 2016, at 2:50 PM, Kumar Srinivasan wrote: > > Hi All, > > Please review the following build changes: > > JDK changes: > * simple entry point change > http://cr.openjdk.java.net/~ksrini/8035473/webrev.07/webrev.jdk.0/ > This 1-line change looks fine. > Top forest repo: > * configuration changes to use the new javadoc/doclet implementation > * module dependency changes (Mandy, Alan) > http://cr.openjdk.java.net/~ksrini/8035473/webrev.07/webrev.jdk9.0/ > modules.xml - the new qualified export from javac to jdk.javadoc is okay. jdk.javadoc.doclet and jdk.javadoc.doclet.taglet are exported API, right? They should be listed in modules.xml to export them from jdk.javadoc module. The package-info.java of com.sun.javadoc and com.sun.tools.doclets says they are superseded by the new jdk.javadoc.doclet package. Should the existing ones be deprecated? Mandy From magnus.ihse.bursie at oracle.com Fri Jan 22 23:41:08 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 23 Jan 2016 00:41:08 +0100 Subject: 8035473: [javadoc] Revamp the existing Doclet APIs In-Reply-To: <56A2B236.7060001@oracle.com> References: <56A2B236.7060001@oracle.com> Message-ID: <56A2BE14.9030009@oracle.com> On 2016-01-22 23:50, Kumar Srinivasan wrote: > Hi All, > > Please review the following build changes: > > JDK changes: > * simple entry point change > http://cr.openjdk.java.net/~ksrini/8035473/webrev.07/webrev.jdk.0/ Looks good. > > Top forest repo: > * configuration changes to use the new javadoc/doclet implementation > * module dependency changes (*Mandy, Alan*) > http://cr.openjdk.java.net/~ksrini/8035473/webrev.07/webrev.jdk9.0/ In make/Javadoc.gmk: What's the story with all these old doclet duplication? > > Langtools changes: > * please review the build portions, ie. > make/CompileInterim.gmk > make/gensrc/Gensrc-jdk.javadoc.gmk > make/netbeans/langtools/build.xml > * core javadoc changes are reviewed by Jan, Jon, Bhavesh, Oleg, Vicente > http://cr.openjdk.java.net/~ksrini/8035473/webrev.07/webrev.langtools.0/ In make/gensrc/Gensrc-jdk.javadoc.gmk: Did you mean to remove the old javadoc version.properties? If not, and you want two files from now on, you need to give them unique names as the first argument, e.g. OLD_JAVADOC_VERSION and JAVADOC_VERSION, or something like that. /Magnus > > Thanks > Kumar > From jonathan.gibbons at oracle.com Fri Jan 22 23:49:55 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 22 Jan 2016 15:49:55 -0800 Subject: 8035473: [javadoc] Revamp the existing Doclet APIs In-Reply-To: <56A2BE14.9030009@oracle.com> References: <56A2B236.7060001@oracle.com> <56A2BE14.9030009@oracle.com> Message-ID: <56A2C023.4060803@oracle.com> On 01/22/2016 03:41 PM, Magnus Ihse Bursie wrote: > > In make/Javadoc.gmk: > What's the story with all these old doclet duplication? The story is that we're adding a completely new public API, and there are existing users of the existing API, both good and bad. The good ones are just using the Doclet API itself (and providing their own doclet), the bad ones are using and overriding classes in the (internal) implementation of the standard doclet. Since we have not hitherto given notice about anything going away, for the time being we'll keep old and new side by side. The informal unofficial expectation is that we'll give the bad users 1 release to convert their code (and delete the old standard doclet in 10), and we'll maybe give the good users 2 releases to change their code (and delete the old API in 11). -- Jon From kumar.x.srinivasan at oracle.com Sat Jan 23 23:18:11 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Sat, 23 Jan 2016 15:18:11 -0800 Subject: 8035473: [javadoc] Revamp the existing Doclet APIs In-Reply-To: <56A2BE14.9030009@oracle.com> References: <56A2B236.7060001@oracle.com> <56A2BE14.9030009@oracle.com> Message-ID: <56A40A33.8060106@oracle.com> HI Magnus, > In make/gensrc/Gensrc-jdk.javadoc.gmk: > Did you mean to remove the old javadoc version.properties? If not, and > you want two files from now on, you need to give them unique names as > the first argument, e.g. OLD_JAVADOC_VERSION and JAVADOC_VERSION, or > something like that. Is this sufficient or were you think of something else ? hg-dev9-javadoc % hg diff diff --git a/make/gensrc/Gensrc-jdk.javadoc.gmk b/make/gensrc/Gensrc-jdk.javadoc.gmk --- a/make/gensrc/Gensrc-jdk.javadoc.gmk +++ b/make/gensrc/Gensrc-jdk.javadoc.gmk @@ -25,7 +25,7 @@ include GensrcCommon.gmk -$(eval $(call SetupVersionProperties,JAVADOC_VERSION,\ +$(eval $(call SetupVersionProperties,OLD_JAVADOC_VERSION,\ com/sun/tools/javadoc/resources/version.properties)) $(eval $(call SetupVersionProperties,JAVADOC_VERSION,\ Please let me know. I will accumulate other changes and spin a final review. Thanks Kumar > > /Magnus > >> >> Thanks >> Kumar >> > From magnus.ihse.bursie at oracle.com Sun Jan 24 08:56:44 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sun, 24 Jan 2016 09:56:44 +0100 Subject: RFR: JDK-8148120 Incremental update from build-infra project Message-ID: <56A491CC.4010409@oracle.com> This patch contains a series of small fixes of general applicability that have been created in the build-infra project. These are: * Add missing llvm library dependency * Improve compare script for static libraries * Simplify LogFailures interface, and add support for storing command lines * Hide "Creating library *.lib and object *.exp" text when linking on Windows * Fix problems with smartjavac when using the build-compare functionality * When repeating output, truncate it if too long Bug: https://bugs.openjdk.java.net/browse/JDK-8148120 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8148120-incremental-updates-from-build-infra/webrev.01 /Magnus From andreas.lundblad at oracle.com Sun Jan 24 11:33:43 2016 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Sun, 24 Jan 2016 12:33:43 +0100 Subject: javac server: No port file values materialized. on AIX In-Reply-To: References: <56975720.2010606@oracle.com> <20160114122303.GD14798@e6430> <20160117170810.GA26924@e6430> <569C95A5.50409@oracle.com> <20160118143441.GA13405@e6430> Message-ID: <20160124113343.GB22521@e6430> On Mon, Jan 18, 2016 at 03:39:39PM +0100, Volker Simonis wrote: > On Mon, Jan 18, 2016 at 3:34 PM, Andreas Lundblad > wrote: > >> >> Interesting observation. The code for waiting for valid port file values > >> >> basically looks like > >> >> > >> >> for (int i = 0; i < 10; i++) { > >> >> checkPortFile(); > >> >> if (successful) > >> >> break; > >> >> sleep(500); > >> >> } > >> >> > >> >> so the fact that it even reaches 6676 ms looks suspicious when it comes to > >> >> load. > >> > > >> > > >> > Why? Under load those sleep(500)'s might not return for much longer; and the > >> > whole things might be time preempted at any point for an extended period of > >> > time. > > > > What I meant was that the fact that the code takes 6676 ms to complete increases my suspicion about it being due to a load issue. > > > > > >> What about putting another loop around this loop which prints a > >> warning to stdout (e.g. "..trying to connect to sjavac server since X > >> seconds") for another five or so times. We could also print the system > >> load [1] although I'm not sure it's worth it. On our AIX machines it > >> is often a network/NFS problem which causes long startup times of new > >> executables and this won't be observable by looking at the system load > >> (but it may at least give a hint'). > >> > >> [1] http://docs.oracle.com/javase/6/docs/api/java/lang/management/OperatingSystemMXBean.html#getSystemLoadAverage%28%29 > > > > I don't think a loop around the loop is necessary. The actual code (which is slightly different from the snippet I posted above) already prints a message between each attempt. > > > > I was thinking of just bumping the timeout from 5 seconds to, say, 60 seconds. If it's a load issue, we should se something like "Port file values found after 9000 ms", in which case we know for sure that it was a premature timeout issue. If no port files materialize after >60 seconds, we can probably safely assume that the issue is due to something else. > > > > Sounds good. Let's try it. Patch has now been pushed [1]. Please let me know if any of you still experience the "No portfile values materialized" problem. -- Andreas [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/3e4edb085bf0 From erik.joelsson at oracle.com Mon Jan 25 08:13:24 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 25 Jan 2016 09:13:24 +0100 Subject: RFR: JDK-8148120 Incremental update from build-infra project In-Reply-To: <56A491CC.4010409@oracle.com> References: <56A491CC.4010409@oracle.com> Message-ID: <56A5D924.1080902@oracle.com> In NativeCompilation.gmk, the exit value saving for linking is most likely redundant. I managed to remove that for the compile command lines. There I verified that failed compiles still failed the build, without the need for exitvalue saving. I do believe this was relying on the -e switch to bash (I tried both with and without that and pipefail to be sure which was required), but we do have that always on windows. /Erik On 2016-01-24 09:56, Magnus Ihse Bursie wrote: > This patch contains a series of small fixes of general applicability > that have been created in the build-infra project. These are: > > * Add missing llvm library dependency > * Improve compare script for static libraries > * Simplify LogFailures interface, and add support for storing command > lines > * Hide "Creating library *.lib and object *.exp" text when linking on > Windows > * Fix problems with smartjavac when using the build-compare functionality > * When repeating output, truncate it if too long > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148120 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8148120-incremental-updates-from-build-infra/webrev.01 > > /Magnus > From thomas.stuefe at gmail.com Mon Jan 25 08:40:05 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 Jan 2016 09:40:05 +0100 Subject: javac server: No port file values materialized. on AIX In-Reply-To: <20160124113343.GB22521@e6430> References: <56975720.2010606@oracle.com> <20160114122303.GD14798@e6430> <20160117170810.GA26924@e6430> <569C95A5.50409@oracle.com> <20160118143441.GA13405@e6430> <20160124113343.GB22521@e6430> Message-ID: Hi Andreas, thanks! I will use this patch on my AIX builds. I will come back to you if the error resurfaces. Kind Regards, Thoams On Sun, Jan 24, 2016 at 12:33 PM, Andreas Lundblad < andreas.lundblad at oracle.com> wrote: > On Mon, Jan 18, 2016 at 03:39:39PM +0100, Volker Simonis wrote: > > On Mon, Jan 18, 2016 at 3:34 PM, Andreas Lundblad > > wrote: > > >> >> Interesting observation. The code for waiting for valid port file > values > > >> >> basically looks like > > >> >> > > >> >> for (int i = 0; i < 10; i++) { > > >> >> checkPortFile(); > > >> >> if (successful) > > >> >> break; > > >> >> sleep(500); > > >> >> } > > >> >> > > >> >> so the fact that it even reaches 6676 ms looks suspicious when it > comes to > > >> >> load. > > >> > > > >> > > > >> > Why? Under load those sleep(500)'s might not return for much > longer; and the > > >> > whole things might be time preempted at any point for an extended > period of > > >> > time. > > > > > > What I meant was that the fact that the code takes 6676 ms to complete > increases my suspicion about it being due to a load issue. > > > > > > > > >> What about putting another loop around this loop which prints a > > >> warning to stdout (e.g. "..trying to connect to sjavac server since X > > >> seconds") for another five or so times. We could also print the system > > >> load [1] although I'm not sure it's worth it. On our AIX machines it > > >> is often a network/NFS problem which causes long startup times of new > > >> executables and this won't be observable by looking at the system load > > >> (but it may at least give a hint'). > > >> > > >> [1] > http://docs.oracle.com/javase/6/docs/api/java/lang/management/OperatingSystemMXBean.html#getSystemLoadAverage%28%29 > > > > > > I don't think a loop around the loop is necessary. The actual code > (which is slightly different from the snippet I posted above) already > prints a message between each attempt. > > > > > > I was thinking of just bumping the timeout from 5 seconds to, say, 60 > seconds. If it's a load issue, we should se something like "Port file > values found after 9000 ms", in which case we know for sure that it was a > premature timeout issue. If no port files materialize after >60 seconds, we > can probably safely assume that the issue is due to something else. > > > > > > > Sounds good. Let's try it. > > Patch has now been pushed [1]. > > Please let me know if any of you still experience the "No portfile values > materialized" problem. > > -- Andreas > > [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/3e4edb085bf0 > From Alan.Bateman at oracle.com Mon Jan 25 12:10:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Jan 2016 12:10:03 +0000 Subject: 8035473: [javadoc] Revamp the existing Doclet APIs In-Reply-To: <56A2B236.7060001@oracle.com> References: <56A2B236.7060001@oracle.com> Message-ID: <56A6109B.4030604@oracle.com> On 22/01/2016 22:50, Kumar Srinivasan wrote: > Hi All, > > Please review the following build changes: > > JDK changes: > * simple entry point change > http://cr.openjdk.java.net/~ksrini/8035473/webrev.07/webrev.jdk.0/ > > Top forest repo: > * configuration changes to use the new javadoc/doclet implementation > * module dependency changes (*Mandy, Alan*) > http://cr.openjdk.java.net/~ksrini/8035473/webrev.07/webrev.jdk9.0/ > > As Mandy said, modules.xml should declare the exports. We'll up the module declaration (module-info.java) once these changes get to jake. -Alan. From maurizio.cimadamore at oracle.com Mon Jan 25 12:43:21 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 25 Jan 2016 12:43:21 +0000 Subject: question on jigsaw build Message-ID: <56A61869.2020802@oracle.com> Hi, the current build system in JDK 9 has a way to recover all the source dirs for a given module, by doing something like this: $(call ALL_SRC_DIRS,$(mod)) That is, the build system exports a function that can be passed a module name and will return all the source roots for the module with that name. This is an extremely helpful piece of functionality when building things like IDE support - as one can leverage the knowledge of the build system in order to put together an IDE projects with the right paths in it, regardless of the OS and ARCH (details which are all taken care of by the build itself). I see that this functionality is now removed from the current jigsaw build - which instead declares a sequence of (dynamically defined) targets to compile a module with name xyz; as a result, the variables containing the source roots for xyz are not exported anymore, thus severely impacting usability from 3rd party build tools. What is the plan in this direction? Is there any talks about having the build system export a pseudo API for querying variables (source roots, generated sources, output dirs) for a given module w/o compiling them? Thanks Maurizio From magnus.ihse.bursie at oracle.com Mon Jan 25 13:51:57 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 25 Jan 2016 14:51:57 +0100 Subject: RFR: JDK-8148120 Incremental update from build-infra project In-Reply-To: <56A5D924.1080902@oracle.com> References: <56A491CC.4010409@oracle.com> <56A5D924.1080902@oracle.com> Message-ID: <56A6287D.1020408@oracle.com> On 2016-01-25 09:13, Erik Joelsson wrote: > In NativeCompilation.gmk, the exit value saving for linking is most > likely redundant. I managed to remove that for the compile command > lines. There I verified that failed compiles still failed the build, > without the need for exitvalue saving. I do believe this was relying > on the -e switch to bash (I tried both with and without that and > pipefail to be sure which was required), but we do have that always on > windows. Aha, nice. I based the new link code on the old compile-call version, and when I merged in your new updates I didn't realize that the code I based it on had been simplified. Updated webrev: (only NativeCompilation.gmk changed) http://cr.openjdk.java.net/~ihse/JDK-8148120-incremental-updates-from-build-infra/webrev.02 /Magnus > > /Erik > > On 2016-01-24 09:56, Magnus Ihse Bursie wrote: >> This patch contains a series of small fixes of general applicability >> that have been created in the build-infra project. These are: >> >> * Add missing llvm library dependency >> * Improve compare script for static libraries >> * Simplify LogFailures interface, and add support for storing command >> lines >> * Hide "Creating library *.lib and object *.exp" text when linking on >> Windows >> * Fix problems with smartjavac when using the build-compare >> functionality >> * When repeating output, truncate it if too long >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8148120 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8148120-incremental-updates-from-build-infra/webrev.01 >> >> /Magnus >> > From magnus.ihse.bursie at oracle.com Mon Jan 25 14:19:19 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 25 Jan 2016 15:19:19 +0100 Subject: 8035473: [javadoc] Revamp the existing Doclet APIs In-Reply-To: <56A40A33.8060106@oracle.com> References: <56A2B236.7060001@oracle.com> <56A2BE14.9030009@oracle.com> <56A40A33.8060106@oracle.com> Message-ID: <56A62EE7.60402@oracle.com> On 2016-01-24 00:18, Kumar Srinivasan wrote: > HI Magnus, > >> In make/gensrc/Gensrc-jdk.javadoc.gmk: >> Did you mean to remove the old javadoc version.properties? If not, >> and you want two files from now on, you need to give them unique >> names as the first argument, e.g. OLD_JAVADOC_VERSION and >> JAVADOC_VERSION, or something like that. > Is this sufficient or were you think of something else ? That's fine. /Magnus > > hg-dev9-javadoc % hg diff > diff --git a/make/gensrc/Gensrc-jdk.javadoc.gmk > b/make/gensrc/Gensrc-jdk.javadoc.gmk > --- a/make/gensrc/Gensrc-jdk.javadoc.gmk > +++ b/make/gensrc/Gensrc-jdk.javadoc.gmk > @@ -25,7 +25,7 @@ > > include GensrcCommon.gmk > > -$(eval $(call SetupVersionProperties,JAVADOC_VERSION,\ > +$(eval $(call SetupVersionProperties,OLD_JAVADOC_VERSION,\ > com/sun/tools/javadoc/resources/version.properties)) > > $(eval $(call SetupVersionProperties,JAVADOC_VERSION,\ > > Please let me know. > I will accumulate other changes and spin a final review. > > Thanks > Kumar > >> >> /Magnus >> >>> >>> Thanks >>> Kumar >>> >> > From magnus.ihse.bursie at oracle.com Mon Jan 25 14:20:30 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 25 Jan 2016 15:20:30 +0100 Subject: 8035473: [javadoc] Revamp the existing Doclet APIs In-Reply-To: <56A2C023.4060803@oracle.com> References: <56A2B236.7060001@oracle.com> <56A2BE14.9030009@oracle.com> <56A2C023.4060803@oracle.com> Message-ID: <56A62F2E.2020204@oracle.com> On 2016-01-23 00:49, Jonathan Gibbons wrote: > > > On 01/22/2016 03:41 PM, Magnus Ihse Bursie wrote: >> >> In make/Javadoc.gmk: >> What's the story with all these old doclet duplication? > > The story is that we're adding a completely new public API, and there > are existing users of the existing API, both good and bad. The good > ones are just using the Doclet API itself (and providing their own > doclet), the bad ones are using and overriding classes in the > (internal) implementation of the standard doclet. Since we have not > hitherto given notice about anything going away, for the time being > we'll keep old and new side by side. And we still have users of the old API internally in the JDK? Are the plan for them to go away in a JDK 10 frame as well, or will we convert all the old one's to the new format in JDK 9, so the current duplication in Javadoc.gmk is only temporary? /Magnus > > The informal unofficial expectation is that we'll give the bad users 1 > release to convert their code (and delete the old standard doclet in > 10), and we'll maybe give the good users 2 releases to change their > code (and delete the old API in 11). > > -- Jon > From david.dehaven at oracle.com Mon Jan 25 15:20:05 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 25 Jan 2016 07:20:05 -0800 Subject: Configure(still?) broken on OS X In-Reply-To: <56A0A3E5.7040700@oracle.com> References: <569755E6.7060208@oracle.com> <5697B9B5.8020801@oracle.com> <7D4506AF-6FBA-4622-9DF8-854846C5CB63@oracle.com> <48A957F8-2F29-4AEE-85F0-824104A04ADA@oracle.com> <56A0A3E5.7040700@oracle.com> Message-ID: <83E22188-D6E6-4F84-AEE6-35EC3F5DADE4@oracle.com> >>>> This came up a while back, probably on another list... >>>> >>>> XQuartz had to change the install location due to 10.11 not allowing installation to /usr/X11, so our configure script should be updated to also check in /opt/X11 now. I don't know if a bug was ever filed for this or not. >>>> >>>> To answer the earlier question: Yes, freetype is required for OpenJDK builds on Mac. >>> Incidentally, I have the same version of XQuartz installed on 10.10.5 and it creates symlinks: >>> /usr/X11 -> /opt/X11 >>> /usr/X11R6 -> /opt/X11 >>> >>> but those symlinks cannot be created on 10.11 for the aforementioned reason. >>> >>> -DrD- >>> >> I filed an issue to fix this and provided a proposed fix, but I've not tested it at all (and I can't at the moment...) >> https://bugs.openjdk.java.net/browse/JDK-8147754 > > I think we can be reasonably sure that if --with-freetype=/opt/X11 works, then your fix is working. > > I think your fix looks okay (apart from indentation but that might be Jira messing), but for formalitys sake I'd like you to send out a formal RFR. You don't need to create a webrev, the patch inline is ok. Yeah, that's JIRA messing up the indentation. I've not found a way to use preformatted blocks in JIRA comments yet. I'll post an official RFR later this morning. -DrD- From david.dehaven at oracle.com Mon Jan 25 15:20:05 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 25 Jan 2016 07:20:05 -0800 Subject: Configure(still?) broken on OS X In-Reply-To: <56A0A3E5.7040700@oracle.com> References: <569755E6.7060208@oracle.com> <5697B9B5.8020801@oracle.com> <7D4506AF-6FBA-4622-9DF8-854846C5CB63@oracle.com> <48A957F8-2F29-4AEE-85F0-824104A04ADA@oracle.com> <56A0A3E5.7040700@oracle.com> Message-ID: <83E22188-D6E6-4F84-AEE6-35EC3F5DADE4@oracle.com> >>>> This came up a while back, probably on another list... >>>> >>>> XQuartz had to change the install location due to 10.11 not allowing installation to /usr/X11, so our configure script should be updated to also check in /opt/X11 now. I don't know if a bug was ever filed for this or not. >>>> >>>> To answer the earlier question: Yes, freetype is required for OpenJDK builds on Mac. >>> Incidentally, I have the same version of XQuartz installed on 10.10.5 and it creates symlinks: >>> /usr/X11 -> /opt/X11 >>> /usr/X11R6 -> /opt/X11 >>> >>> but those symlinks cannot be created on 10.11 for the aforementioned reason. >>> >>> -DrD- >>> >> I filed an issue to fix this and provided a proposed fix, but I've not tested it at all (and I can't at the moment...) >> https://bugs.openjdk.java.net/browse/JDK-8147754 > > I think we can be reasonably sure that if --with-freetype=/opt/X11 works, then your fix is working. > > I think your fix looks okay (apart from indentation but that might be Jira messing), but for formalitys sake I'd like you to send out a formal RFR. You don't need to create a webrev, the patch inline is ok. Yeah, that's JIRA messing up the indentation. I've not found a way to use preformatted blocks in JIRA comments yet. I'll post an official RFR later this morning. -DrD- From kumar.x.srinivasan at oracle.com Mon Jan 25 15:49:52 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 25 Jan 2016 07:49:52 -0800 Subject: 8035473: [javadoc] Revamp the existing Doclet APIs In-Reply-To: <56A6109B.4030604@oracle.com> References: <56A2B236.7060001@oracle.com> <56A6109B.4030604@oracle.com> Message-ID: <56A64420.8060306@oracle.com> HI Alan, Mandy, Does this look right ? jdk.javadoc java.base java.compiler java.xml jdk.compiler com.sun.javadoc com.sun.tools.doclets com.sun.tools.javadoc + + jdk.javadoc.doclet + + + jdk.javadoc.doclet.taglet + Thanks Kumar > > > On 22/01/2016 22:50, Kumar Srinivasan wrote: >> Hi All, >> >> Please review the following build changes: >> >> JDK changes: >> * simple entry point change >> http://cr.openjdk.java.net/~ksrini/8035473/webrev.07/webrev.jdk.0/ >> >> Top forest repo: >> * configuration changes to use the new javadoc/doclet implementation >> * module dependency changes (*Mandy, Alan*) >> http://cr.openjdk.java.net/~ksrini/8035473/webrev.07/webrev.jdk9.0/ >> >> > As Mandy said, modules.xml should declare the exports. We'll up the > module declaration (module-info.java) once these changes get to jake. > > -Alan. > From Alan.Bateman at oracle.com Mon Jan 25 16:01:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Jan 2016 16:01:13 +0000 Subject: 8035473: [javadoc] Revamp the existing Doclet APIs In-Reply-To: <56A64420.8060306@oracle.com> References: <56A2B236.7060001@oracle.com> <56A6109B.4030604@oracle.com> <56A64420.8060306@oracle.com> Message-ID: <56A646C9.8040901@oracle.com> On 25/01/2016 15:49, Kumar Srinivasan wrote: > HI Alan, Mandy, > > Does this look right ? > > + > + jdk.javadoc.doclet > + > + > + jdk.javadoc.doclet.taglet > + > > Yes, this looks right. -Alan From mandy.chung at oracle.com Mon Jan 25 17:23:55 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 Jan 2016 09:23:55 -0800 Subject: 8035473: [javadoc] Revamp the existing Doclet APIs In-Reply-To: <56A64420.8060306@oracle.com> References: <56A2B236.7060001@oracle.com> <56A6109B.4030604@oracle.com> <56A64420.8060306@oracle.com> Message-ID: > On Jan 25, 2016, at 7:49 AM, Kumar Srinivasan wrote: > > HI Alan, Mandy, > > Does this look right ? > > > jdk.javadoc > java.base > java.compiler > java.xml > jdk.compiler > > com.sun.javadoc > > > com.sun.tools.doclets > > > com.sun.tools.javadoc > > + > + jdk.javadoc.doclet > + > + > + jdk.javadoc.doclet.taglet > + > Yes, that?s right. Mandy From gnu.andrew at redhat.com Mon Jan 25 20:38:58 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 Jan 2016 15:38:58 -0500 (EST) Subject: [rfc] Avoid failure when compiler is wrapped. In-Reply-To: <56A22417.4080008@redhat.com> References: <56A22417.4080008@redhat.com> Message-ID: <325639192.12248921.1453754338848.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello! > > When compiler is wrapped, the configure phase of build fails: > > [...] > checking for gcc... /usr/lib64/cscppc/gcc > configure: Resolving CC (as /usr/lib64/cscppc/gcc) failed, using > /usr/lib64/cscppc/gcc directly. > checking resolved symbolic links for CC... /usr/bin/cscppc > checking if CC is disguised ccache... no, keeping CC > configure: The C compiler (located as /usr/bin/cscppc) does not seem to be > the required GCC compiler. > configure: The result from running with --version was: "Usage:" > configure: error: GCC compiler is required. Try setting --with-tools-dir. > configure exiting with result code 1 > > > From time to time I'm building RPMS for fedora with wrapped compiler to be > able to investigate C > code changes. Added is patch, which is allowing to walk around the issue. > > I'm wondering if this is still desired behaviour. or if it can be better > iff-ed out to be by default > on, but eg only disablef on AIX. > > CCed is Andrew, who is facing similar issue on Gentoo. > > > Thanx! > J. > The Gentoo issue was different; it's related to distcc failing the version test, rather than symlink issues. I think this block should be removed, not just comment out, if not needed. But first, I think we need to know why the dereferencing is there. Can someone at Oracle shed some light on this? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From david.dehaven at oracle.com Mon Jan 25 15:20:05 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 25 Jan 2016 07:20:05 -0800 Subject: Configure(still?) broken on OS X In-Reply-To: <56A0A3E5.7040700@oracle.com> References: <569755E6.7060208@oracle.com> <5697B9B5.8020801@oracle.com> <7D4506AF-6FBA-4622-9DF8-854846C5CB63@oracle.com> <48A957F8-2F29-4AEE-85F0-824104A04ADA@oracle.com> <56A0A3E5.7040700@oracle.com> Message-ID: <83E22188-D6E6-4F84-AEE6-35EC3F5DADE4@oracle.com> >>>> This came up a while back, probably on another list... >>>> >>>> XQuartz had to change the install location due to 10.11 not allowing installation to /usr/X11, so our configure script should be updated to also check in /opt/X11 now. I don't know if a bug was ever filed for this or not. >>>> >>>> To answer the earlier question: Yes, freetype is required for OpenJDK builds on Mac. >>> Incidentally, I have the same version of XQuartz installed on 10.10.5 and it creates symlinks: >>> /usr/X11 -> /opt/X11 >>> /usr/X11R6 -> /opt/X11 >>> >>> but those symlinks cannot be created on 10.11 for the aforementioned reason. >>> >>> -DrD- >>> >> I filed an issue to fix this and provided a proposed fix, but I've not tested it at all (and I can't at the moment...) >> https://bugs.openjdk.java.net/browse/JDK-8147754 > > I think we can be reasonably sure that if --with-freetype=/opt/X11 works, then your fix is working. > > I think your fix looks okay (apart from indentation but that might be Jira messing), but for formalitys sake I'd like you to send out a formal RFR. You don't need to create a webrev, the patch inline is ok. Yeah, that's JIRA messing up the indentation. I've not found a way to use preformatted blocks in JIRA comments yet. I'll post an official RFR later this morning. -DrD- From jonathan.gibbons at oracle.com Tue Jan 26 07:49:01 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 25 Jan 2016 23:49:01 -0800 Subject: 8035473: [javadoc] Revamp the existing Doclet APIs In-Reply-To: <56A62F2E.2020204@oracle.com> References: <56A2B236.7060001@oracle.com> <56A2BE14.9030009@oracle.com> <56A2C023.4060803@oracle.com> <56A62F2E.2020204@oracle.com> Message-ID: <56A724ED.1060206@oracle.com> On 01/25/2016 06:20 AM, Magnus Ihse Bursie wrote: > On 2016-01-23 00:49, Jonathan Gibbons wrote: >> >> >> On 01/22/2016 03:41 PM, Magnus Ihse Bursie wrote: >>> >>> In make/Javadoc.gmk: >>> What's the story with all these old doclet duplication? >> >> The story is that we're adding a completely new public API, and there >> are existing users of the existing API, both good and bad. The good >> ones are just using the Doclet API itself (and providing their own >> doclet), the bad ones are using and overriding classes in the >> (internal) implementation of the standard doclet. Since we have not >> hitherto given notice about anything going away, for the time being >> we'll keep old and new side by side. > > And we still have users of the old API internally in the JDK? Are the > plan for them to go away in a JDK 10 frame as well, or will we convert > all the old one's to the new format in JDK 9, so the current > duplication in Javadoc.gmk is only temporary? > > /Magnus There are existing usages of the old doclet API that will not be converted before we ship JDK 9, so the old and new code will need to exist side by side at least through the lifetime of JDK 9, while we decide how and when to retire the old code. -- Jon From magnus.ihse.bursie at oracle.com Tue Jan 26 10:47:07 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 26 Jan 2016 11:47:07 +0100 Subject: 8035473: [javadoc] Revamp the existing Doclet APIs In-Reply-To: <56A724ED.1060206@oracle.com> References: <56A2B236.7060001@oracle.com> <56A2BE14.9030009@oracle.com> <56A2C023.4060803@oracle.com> <56A62F2E.2020204@oracle.com> <56A724ED.1060206@oracle.com> Message-ID: <56A74EAB.5000706@oracle.com> On 2016-01-26 08:49, Jonathan Gibbons wrote: > On 01/25/2016 06:20 AM, Magnus Ihse Bursie wrote: >> On 2016-01-23 00:49, Jonathan Gibbons wrote: >>> >>> >>> On 01/22/2016 03:41 PM, Magnus Ihse Bursie wrote: >>>> >>>> In make/Javadoc.gmk: >>>> What's the story with all these old doclet duplication? >>> >>> The story is that we're adding a completely new public API, and >>> there are existing users of the existing API, both good and bad. The >>> good ones are just using the Doclet API itself (and providing their >>> own doclet), the bad ones are using and overriding classes in the >>> (internal) implementation of the standard doclet. Since we have not >>> hitherto given notice about anything going away, for the time being >>> we'll keep old and new side by side. >> >> And we still have users of the old API internally in the JDK? Are the >> plan for them to go away in a JDK 10 frame as well, or will we >> convert all the old one's to the new format in JDK 9, so the current >> duplication in Javadoc.gmk is only temporary? >> >> /Magnus > > There are existing usages of the old doclet API that will not be > converted before we ship JDK 9, so the old and new code will need to > exist side by side at least through the lifetime of JDK 9, while we > decide how and when to retire the old code. Ok, I see. Then I'm satisfied with the review from a build perspective. /Magnus > > -- Jon From bob.vandette at oracle.com Tue Jan 26 19:50:11 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 26 Jan 2016 14:50:11 -0500 Subject: RFR: 8148302: Initial Bringup of Android in mobile/dev Message-ID: <86B4D3CB-E8ED-4857-A18E-B590C2BECB8F@oracle.com> Please review the changes for two improvements for the Mobile Dev Forest. With these changes, the mobile/dev forest can successfully build x86 and ARM Android JDK 9 binaries. The ARM binaries use the Zero ARM interpreter while the x86 implementation uses standard x86 Hotspot VMs. The webrev also includes 1 fix for iOS BSD builds in hotspot/make/bsd/makefiles/vm.make. JDK-8148304 Mobile: iOS builds fail on assembler files https://bugs.openjdk.java.net/browse/JDK-8148304 JDK-8148302 Mobile: Initial bring of Android x86 and ARM https://bugs.openjdk.java.net/browse/JDK-8148302 Here?s the webrev: http://cr.openjdk.java.net/~bobv/8148302/webrev Bob. From magnus.ihse.bursie at oracle.com Wed Jan 27 09:56:54 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Jan 2016 10:56:54 +0100 Subject: RFR: 8148302: Initial Bringup of Android in mobile/dev In-Reply-To: <86B4D3CB-E8ED-4857-A18E-B590C2BECB8F@oracle.com> References: <86B4D3CB-E8ED-4857-A18E-B590C2BECB8F@oracle.com> Message-ID: <56A89466.6030502@oracle.com> On 2016-01-26 20:50, Bob Vandette wrote: > Please review the changes for two improvements for the Mobile Dev Forest. > > With these changes, the mobile/dev forest can successfully build x86 and ARM Android > JDK 9 binaries. The ARM binaries use the Zero ARM interpreter while the x86 > implementation uses standard x86 Hotspot VMs. > > The webrev also includes 1 fix for iOS BSD builds in hotspot/make/bsd/makefiles/vm.make. > > JDK-8148304 Mobile: iOS builds fail on assembler files > https://bugs.openjdk.java.net/browse/JDK-8148304 > > JDK-8148302 Mobile: Initial bring of Android x86 and ARM > https://bugs.openjdk.java.net/browse/JDK-8148302 > > Here?s the webrev: > > http://cr.openjdk.java.net/~bobv/8148302/webrev Hi Bob, Some comments: * In jni_util_md.c, you have accidentally lost a trailing ). * In spec.gmk.in, please use ":=" instead of "=". The former is assignment, the latter is used for macro expansion. (As a rule of thumb, := should always be used unless you have explicit reasons.) * In CompileJavaModules.gmk, why do you remove the exclude for BUILD_HEADLESS_ONLY? This change affects all platforms, not only android. * In lib-x11.m4, I *really* don't like adding X11 paths when we should not have X11! (And it's even worse since you do not check for Android but do so for all platforms.) What files are needed, and for what library? Can you not fix this dependency by removing the #include statements in the source code instead? Otherwise, I'd say that android *is* indeed dependent on X11, and you need to express this properly. * In lib-ffi.m4 and Copy-java.base.gmk: I think this a bit problematic. I believe what you're trying to achieve is similar to what we do for freetype, where we "bundle" the library with the resulting product. I'd rather see this libffi bundling based on that behavior. More concretely: - The name of the variable should be like LIBFFI_BUNDLE_LIB_PATH, to clearly show that this is used only when bundling the product, not when compiling it. - Whether to bundle or not should be determined in lib-ffi.m4. The default value should be "bundle if android+zero, otherwise not". If you want to, you can add a --enable-libffi-bundling to override this. I won't require it, but I generally find such things useful since you can test that bundling works even without building for a specific target. The code in Copy-java.base.gmk should then only test if this variable is present, compare with freetype in Copy-java.desktop. Finally, the configure code must check for the case that libffi bundling is enabled but no explicit libffi path is set (e.g. it is autodetected). It's okay to abort with an error, but it must be detected. And finally, a note of appreciation. :-) I'm really happy to see the ugly solution with the hard-coded linker scripts go away in flags.m4! /Magnus From magnus.ihse.bursie at oracle.com Wed Jan 27 10:09:21 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Jan 2016 11:09:21 +0100 Subject: [rfc] Avoid failure when compiler is wrapped. In-Reply-To: <325639192.12248921.1453754338848.JavaMail.zimbra@redhat.com> References: <56A22417.4080008@redhat.com> <325639192.12248921.1453754338848.JavaMail.zimbra@redhat.com> Message-ID: <56A89751.6030300@oracle.com> On 2016-01-25 21:38, Andrew Hughes wrote: > ----- Original Message ----- >> Hello! >> >> When compiler is wrapped, the configure phase of build fails: >> >> [...] >> checking for gcc... /usr/lib64/cscppc/gcc >> configure: Resolving CC (as /usr/lib64/cscppc/gcc) failed, using >> /usr/lib64/cscppc/gcc directly. >> checking resolved symbolic links for CC... /usr/bin/cscppc >> checking if CC is disguised ccache... no, keeping CC >> configure: The C compiler (located as /usr/bin/cscppc) does not seem to be >> the required GCC compiler. >> configure: The result from running with --version was: "Usage:" >> configure: error: GCC compiler is required. Try setting --with-tools-dir. >> configure exiting with result code 1 >> >> >> From time to time I'm building RPMS for fedora with wrapped compiler to be >> able to investigate C >> code changes. Added is patch, which is allowing to walk around the issue. >> >> I'm wondering if this is still desired behaviour. or if it can be better >> iff-ed out to be by default >> on, but eg only disablef on AIX. >> >> CCed is Andrew, who is facing similar issue on Gentoo. >> >> >> Thanx! >> J. >> > The Gentoo issue was different; it's related to distcc failing the version > test, rather than symlink issues. > > I think this block should be removed, not just comment out, if not needed. > But first, I think we need to know why the dereferencing is there. > Can someone at Oracle shed some light on this? Maybe a glow of twilight. :) This check was added quite early in the new build system and was included in the original integration of the new build system into mainline. I remember vaguely that we had issues with some machines with strange setups which turned out to have unexpected symlinks. So we thought it was better to clearly show in the configure log which compiler *really* was used. From the hg history, I also see that about a year ago, I added this comment in JDK-8034788: # FIXME: This test should not be needed anymore; we don't do that for any platform. So maybe we should live up to that fixme, and remove the check. :-) I just realized that we can still keep ability to debug broken systems by resolving the symlink, but just printing the result and not modifying the path to the CC we will use. I opened https://bugs.openjdk.java.net/browse/JDK-8148351 for this. /Magnus From magnus.ihse.bursie at oracle.com Wed Jan 27 10:32:31 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Jan 2016 11:32:31 +0100 Subject: RFR: JDK-8148351 Only display resolved symlink for compiler, do not change path Message-ID: <56A89CBF.9080403@oracle.com> During toolchain detection, if the found compiler (CC or CXX) is a symbolic link, we resolve it and point to the resolved binary. This was introduced to be able to debug systems with a broken setup, but it breaks use cases were a CC wrapper is used. A better solution is to just print the path of the resolved symlink and keep the original value intact. Bug: https://bugs.openjdk.java.net/browse/JDK-8148351 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8148351-do-not-replace-compiler-symlink/webrev.01 /Magnus From gary.adams at oracle.com Wed Jan 27 12:42:13 2016 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 27 Jan 2016 07:42:13 -0500 Subject: RFR: 8148361: Need to disable the thread local storage compiler option for ios Message-ID: <56A8BB25.7040405@oracle.com> When the sync with jdk9 b102 was pulled into mobile/dev repos a new feature for thread local storage was over looked. Most modern compilers include support for thread local declaration, but this feature is intentionally not supported by Apple's clang compiler. This change declares USE_LIBRARY_BASED_TLS_ONLY along with other TARGET_OS_IPHONE declarations in the hotspot globalDefinitions_gcc.hpp file. Issue: https://bugs.openjdk.java.net/browse/JDK-8148361 Webrev: http://cr.openjdk.java.net/~gadams/8148361/webrev.00/ From bertrand.delsart at oracle.com Wed Jan 27 13:15:08 2016 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 27 Jan 2016 14:15:08 +0100 Subject: RFR: 8148361: Need to disable the thread local storage compiler option for ios In-Reply-To: <56A8BB25.7040405@oracle.com> References: <56A8BB25.7040405@oracle.com> Message-ID: <56A8C2DC.4050704@oracle.com> Approved, Bertrand. On 27/01/2016 13:42, Gary Adams wrote: > When the sync with jdk9 b102 was pulled into mobile/dev repos a new > feature for thread local storage was over looked. Most modern compilers > include support for thread local declaration, but this feature is > intentionally > not supported by Apple's clang compiler. > > This change declares USE_LIBRARY_BASED_TLS_ONLY along with other > TARGET_OS_IPHONE declarations in the hotspot globalDefinitions_gcc.hpp > file. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8148361 > Webrev: http://cr.openjdk.java.net/~gadams/8148361/webrev.00/ -- 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 aleksey.shipilev at oracle.com Wed Jan 27 13:55:48 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 27 Jan 2016 16:55:48 +0300 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) Message-ID: <56A8CC64.3080500@oracle.com> Hi again, This is a formal pre-integration review thread for JEP 280 ("Indify String Concatenation") integration: http://openjdk.java.net/jeps/280 The JEP is Targeted, the CCC is approved, the code reviews and pre-integration checks are clean. Code changes are happening simultaneously in four components: a) (M) javac changes that emit indy: http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ b) (L) JDK changes with StringConcatFactory and friends, plus fixing the regression tests that do not expect additional indys: http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ c) (XS) Build changes that force emitting the "legacy" inline StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is expected): http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ d) (XS) HotSpot changes that fix a GC regression test that now allocates some metaspace from within the test methods having a string concatenation: http://cr.openjdk.java.net/~shade/8085796/webrev.hs.00/ These changes were already reviewed by multiple people, and so I would like to keep the comments only for serious breaking issues at this point. (Note that this thread cross-posts over several mailing lists: bike-shedding discussion would get multiplied a lot!) Formal acknowledgements from Reviewers would be appreciated. Pending no show-stopper comments, I'd like to push this through jdk9/dev in 24 hours. Thanks, -Aleksey From magnus.ihse.bursie at oracle.com Wed Jan 27 14:03:14 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Jan 2016 15:03:14 +0100 Subject: RFR: 8148361: Need to disable the thread local storage compiler option for ios In-Reply-To: <56A8BB25.7040405@oracle.com> References: <56A8BB25.7040405@oracle.com> Message-ID: <56A8CE22.2050803@oracle.com> On 2016-01-27 13:42, Gary Adams wrote: > When the sync with jdk9 b102 was pulled into mobile/dev repos a new > feature for thread local storage was over looked. Most modern compilers > include support for thread local declaration, but this feature is > intentionally > not supported by Apple's clang compiler. > > This change declares USE_LIBRARY_BASED_TLS_ONLY along with other > TARGET_OS_IPHONE declarations in the hotspot globalDefinitions_gcc.hpp > file. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8148361 > Webrev: http://cr.openjdk.java.net/~gadams/8148361/webrev.00/ From my perspective it looks good, but since you're actually modifying the hotspot source code and not make files, someone from the Hotspot team should look at this as well. /Magnus From magnus.ihse.bursie at oracle.com Wed Jan 27 14:07:46 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Jan 2016 15:07:46 +0100 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56A8CC64.3080500@oracle.com> References: <56A8CC64.3080500@oracle.com> Message-ID: <56A8CF32.5060102@oracle.com> On 2016-01-27 14:55, Aleksey Shipilev wrote: > Hi again, > > This is a formal pre-integration review thread for JEP 280 ("Indify > String Concatenation") integration: > http://openjdk.java.net/jeps/280 > > The JEP is Targeted, the CCC is approved, the code reviews and > pre-integration checks are clean. > > Code changes are happening simultaneously in four components: > > a) (M) javac changes that emit indy: > http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ > > b) (L) JDK changes with StringConcatFactory and friends, plus fixing > the regression tests that do not expect additional indys: > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ > > c) (XS) Build changes that force emitting the "legacy" inline > StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is > expected): > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ Aleksey, Build changes look good to me. Just out of curiosity, what does "indy" mean in this context? I have not heard this expression and googling fails to bring up anything relevant. /Magnus > > d) (XS) HotSpot changes that fix a GC regression test that now > allocates some metaspace from within the test methods having a string > concatenation: > http://cr.openjdk.java.net/~shade/8085796/webrev.hs.00/ > > These changes were already reviewed by multiple people, and so I would > like to keep the comments only for serious breaking issues at this > point. (Note that this thread cross-posts over several mailing lists: > bike-shedding discussion would get multiplied a lot!) > > Formal acknowledgements from Reviewers would be appreciated. Pending no > show-stopper comments, I'd like to push this through jdk9/dev in 24 hours. > > Thanks, > -Aleksey > From weijun.wang at oracle.com Wed Jan 27 14:13:02 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 27 Jan 2016 22:13:02 +0800 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56A8CF32.5060102@oracle.com> References: <56A8CC64.3080500@oracle.com> <56A8CF32.5060102@oracle.com> Message-ID: <4BDC0A84-410F-446C-8F49-660E6B418848@oracle.com> > > Just out of curiosity, what does "indy" mean in this context? I have not heard this expression and googling fails to bring up anything relevant. > At first I thought it's Russian, but then -- invokedynamic. --Max From aleksey.shipilev at oracle.com Wed Jan 27 14:33:37 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 27 Jan 2016 17:33:37 +0300 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56A8CF32.5060102@oracle.com> References: <56A8CC64.3080500@oracle.com> <56A8CF32.5060102@oracle.com> Message-ID: <56A8D541.7090904@oracle.com> On 01/27/2016 05:07 PM, Magnus Ihse Bursie wrote: > On 2016-01-27 14:55, Aleksey Shipilev wrote: >> c) (XS) Build changes that force emitting the "legacy" inline >> StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is >> expected): >> http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ > > Build changes look good to me. Thanks! > Just out of curiosity, what does "indy" mean in this context? I have not > heard this expression and googling fails to bring up anything relevant. Yes, "indy" is a frequently-used shortcut for "invokedynamic". I am trying to use the full form outside the close-knit group of indy users, but fail frequently at that! Thanks, -Aleksey From bob.vandette at oracle.com Wed Jan 27 16:15:13 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 27 Jan 2016 11:15:13 -0500 Subject: RFR: 8148302: Initial Bringup of Android in mobile/dev In-Reply-To: <56A89466.6030502@oracle.com> References: <86B4D3CB-E8ED-4857-A18E-B590C2BECB8F@oracle.com> <56A89466.6030502@oracle.com> Message-ID: > On Jan 27, 2016, at 4:56 AM, Magnus Ihse Bursie wrote: > > On 2016-01-26 20:50, Bob Vandette wrote: >> Please review the changes for two improvements for the Mobile Dev Forest. >> >> With these changes, the mobile/dev forest can successfully build x86 and ARM Android >> JDK 9 binaries. The ARM binaries use the Zero ARM interpreter while the x86 >> implementation uses standard x86 Hotspot VMs. >> >> The webrev also includes 1 fix for iOS BSD builds in hotspot/make/bsd/makefiles/vm.make. >> >> JDK-8148304 Mobile: iOS builds fail on assembler files >> https://bugs.openjdk.java.net/browse/JDK-8148304 >> >> JDK-8148302 Mobile: Initial bring of Android x86 and ARM >> https://bugs.openjdk.java.net/browse/JDK-8148302 >> >> Here?s the webrev: >> >> http://cr.openjdk.java.net/~bobv/8148302/webrev > > Hi Bob, > > Some comments: > > * In jni_util_md.c, you have accidentally lost a trailing ). Thanks for catching that. Fixed. > > * In spec.gmk.in, please use ":=" instead of "=". The former is assignment, the latter is used for macro expansion. (As a rule of thumb, := should always be used unless you have explicit reasons.) Fixed. > > * In CompileJavaModules.gmk, why do you remove the exclude for BUILD_HEADLESS_ONLY? This change affects all platforms, not only android. I don?t believe BUILD_HEADLESS_ONLY works for any platform without this fix. Although I specify ?disable-headful and set BUILD_HEADLESS_ONLY, the desktop module is still built and fails compiling several files due to these missing classes. * For target java.desktop: /export/users/bobv/mobile-dev/jdk/src/java.desktop/share/classes/sun/awt/www/content/audio/aiff.java:34: error: package sun.applet does not exist import sun.applet.AppletAudioClip; ^ /export/users/bobv/mobile-dev/jdk/src/java.desktop/share/classes/sun/awt/www/content/audio/basic.java:34: error: package sun.applet does not exist import sun.applet.AppletAudioClip; /export/users/bobv/mobile-dev/jdk/src/java.desktop/share/classes/sun/awt/www/content/audio/wav.java:34: error: package sun.applet does not exist import sun.applet.AppletAudioClip; ^ /export/users/bobv/mobile-dev/jdk/src/java.desktop/share/classes/sun/awt/www/content/audio/x_aiff.java:34: error: package sun.applet does not exist import sun.applet.AppletAudioClip; ^ /export/users/bobv/mobile-dev/jdk/src/java.desktop/share/classes/sun/awt/www/content/audio/x_wav.java:34: error: package sun.applet does not exist import sun.applet.AppletAudioClip; ^ /export/users/bobv/mobile-dev/jdk/src/java.desktop/share/classes/sun/font/SunFontManager.java:2843: error: package sun.applet does not exist return sm instanceof sun.applet.AppletSecurity; > > * In lib-x11.m4, I *really* don't like adding X11 paths when we should not have X11! (And it's even worse since you do not check for Android but do so for all platforms.) What files are needed, and for what library? Can you not fix this dependency by removing the #include statements in the source code instead? Otherwise, I'd say that android *is* indeed dependent on X11, and you need to express this properly. I removed this change. It?s no longer necessary. The change that most likely fixed this is the setting of BUILD_HEADLESS_ONLY. Shouldn?t BUILD_HEADLESS_ONLY be set when ?disable-headful is set to true or maybe the uses of BUILD_HEADLESS_ONLY should be changed to SUPPORT_HEADFUL? > > * In lib-ffi.m4 and Copy-java.base.gmk: I think this a bit problematic. I believe what you're trying to achieve is similar to what we do for freetype, where we "bundle" the library with the resulting product. I'd rather see this libffi bundling based on that behavior. More concretely: > - The name of the variable should be like LIBFFI_BUNDLE_LIB_PATH, to clearly show that this is used only when bundling the product, not when compiling it. Ok. > - Whether to bundle or not should be determined in lib-ffi.m4. The default value should be "bundle if android+zero, otherwise not". If you want to, you can add a --enable-libffi-bundling to override this. I won't require it, but I generally find such things useful since you can test that bundling works even without building for a specific target. The code in Copy-java.base.gmk should then only test if this variable is present, compare with freetype in Copy-java.desktop. Finally, the configure code must check for the case that libffi bundling is enabled but no explicit libffi path is set (e.g. it is autodetected). It's okay to abort with an error, but it must be detected. Yes, I was trying to model this after the freetype library. Ok, I?ll make that change. > > And finally, a note of appreciation. :-) I'm really happy to see the ugly solution with the hard-coded linker scripts go away in flags.m4! They are also removed from the VM makefiles. I?m happy that we don?t need this anymore. This happened when we started generating devkits from the Android NDK. The NDK toolchain generation script generates toolchains that handle the ldscripts for us. Thanks for the review, Bob. > > /Magnus From vladimir.x.ivanov at oracle.com Wed Jan 27 16:47:22 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 27 Jan 2016 19:47:22 +0300 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56A8CC64.3080500@oracle.com> References: <56A8CC64.3080500@oracle.com> Message-ID: <56A8F49A.4050503@oracle.com> JDK changes looks good! Best regards, Vladimir Ivanov On 1/27/16 4:55 PM, Aleksey Shipilev wrote: > Hi again, > > This is a formal pre-integration review thread for JEP 280 ("Indify > String Concatenation") integration: > http://openjdk.java.net/jeps/280 > > The JEP is Targeted, the CCC is approved, the code reviews and > pre-integration checks are clean. > > Code changes are happening simultaneously in four components: > > a) (M) javac changes that emit indy: > http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ > > b) (L) JDK changes with StringConcatFactory and friends, plus fixing > the regression tests that do not expect additional indys: > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ > > c) (XS) Build changes that force emitting the "legacy" inline > StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is > expected): > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ > > d) (XS) HotSpot changes that fix a GC regression test that now > allocates some metaspace from within the test methods having a string > concatenation: > http://cr.openjdk.java.net/~shade/8085796/webrev.hs.00/ > > These changes were already reviewed by multiple people, and so I would > like to keep the comments only for serious breaking issues at this > point. (Note that this thread cross-posts over several mailing lists: > bike-shedding discussion would get multiplied a lot!) > > Formal acknowledgements from Reviewers would be appreciated. Pending no > show-stopper comments, I'd like to push this through jdk9/dev in 24 hours. > > Thanks, > -Aleksey > From jvanek at redhat.com Wed Jan 27 16:54:29 2016 From: jvanek at redhat.com (Jiri Vanek) Date: Wed, 27 Jan 2016 17:54:29 +0100 Subject: [rfc] Avoid failure when compiler is wrapped. In-Reply-To: <56A89751.6030300@oracle.com> References: <56A22417.4080008@redhat.com> <325639192.12248921.1453754338848.JavaMail.zimbra@redhat.com> <56A89751.6030300@oracle.com> Message-ID: <56A8F645.8030501@redhat.com> On 01/27/2016 11:09 AM, Magnus Ihse Bursie wrote: > On 2016-01-25 21:38, Andrew Hughes wrote: >> ----- Original Message ----- >>> Hello! >>> >>> When compiler is wrapped, the configure phase of build fails: >>> >>> [...] >>> checking for gcc... /usr/lib64/cscppc/gcc >>> configure: Resolving CC (as /usr/lib64/cscppc/gcc) failed, using >>> /usr/lib64/cscppc/gcc directly. >>> checking resolved symbolic links for CC... /usr/bin/cscppc >>> checking if CC is disguised ccache... no, keeping CC >>> configure: The C compiler (located as /usr/bin/cscppc) does not seem to be >>> the required GCC compiler. >>> configure: The result from running with --version was: "Usage:" >>> configure: error: GCC compiler is required. Try setting --with-tools-dir. >>> configure exiting with result code 1 >>> >>> >>> From time to time I'm building RPMS for fedora with wrapped compiler to be >>> able to investigate C >>> code changes. Added is patch, which is allowing to walk around the issue. >>> >>> I'm wondering if this is still desired behaviour. or if it can be better >>> iff-ed out to be by default >>> on, but eg only disablef on AIX. >>> >>> CCed is Andrew, who is facing similar issue on Gentoo. >>> >>> >>> Thanx! >>> J. >>> >> The Gentoo issue was different; it's related to distcc failing the version >> test, rather than symlink issues. >> >> I think this block should be removed, not just comment out, if not needed. >> But first, I think we need to know why the dereferencing is there. >> Can someone at Oracle shed some light on this? > > Maybe a glow of twilight. :) This check was added quite early in the new build system and was > included in the original integration of the new build system into mainline. I remember vaguely that > we had issues with some machines with strange setups which turned out to have unexpected symlinks. > So we thought it was better to clearly show in the configure log which compiler *really* was used. > > From the hg history, I also see that about a year ago, I added this comment in JDK-8034788: > # FIXME: This test should not be needed anymore; we don't do that for any platform. > > So maybe we should live up to that fixme, and remove the check. :-) > > I just realized that we can still keep ability to debug broken systems by resolving the symlink, but > just printing the result and not modifying the path to the CC we will use. I opened > https://bugs.openjdk.java.net/browse/JDK-8148351 for this. > Thank you for this Magnus. I will try to prepare regualr webrev based on your suggestion. If you fix it in meantime, just let us know :) Thanx! J From gnu.andrew at redhat.com Wed Jan 27 17:09:57 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 27 Jan 2016 12:09:57 -0500 (EST) Subject: [rfc] Avoid failure when compiler is wrapped. In-Reply-To: <56A89751.6030300@oracle.com> References: <56A22417.4080008@redhat.com> <325639192.12248921.1453754338848.JavaMail.zimbra@redhat.com> <56A89751.6030300@oracle.com> Message-ID: <170646706.13193034.1453914597872.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 2016-01-25 21:38, Andrew Hughes wrote: > > ----- Original Message ----- > >> Hello! > >> > >> When compiler is wrapped, the configure phase of build fails: > >> > >> [...] > >> checking for gcc... /usr/lib64/cscppc/gcc > >> configure: Resolving CC (as /usr/lib64/cscppc/gcc) failed, using > >> /usr/lib64/cscppc/gcc directly. > >> checking resolved symbolic links for CC... /usr/bin/cscppc > >> checking if CC is disguised ccache... no, keeping CC > >> configure: The C compiler (located as /usr/bin/cscppc) does not seem to be > >> the required GCC compiler. > >> configure: The result from running with --version was: "Usage:" > >> configure: error: GCC compiler is required. Try setting --with-tools-dir. > >> configure exiting with result code 1 > >> > >> > >> From time to time I'm building RPMS for fedora with wrapped compiler to > >> be > >> able to investigate C > >> code changes. Added is patch, which is allowing to walk around the issue. > >> > >> I'm wondering if this is still desired behaviour. or if it can be better > >> iff-ed out to be by default > >> on, but eg only disablef on AIX. > >> > >> CCed is Andrew, who is facing similar issue on Gentoo. > >> > >> > >> Thanx! > >> J. > >> > > The Gentoo issue was different; it's related to distcc failing the version > > test, rather than symlink issues. > > > > I think this block should be removed, not just comment out, if not needed. > > But first, I think we need to know why the dereferencing is there. > > Can someone at Oracle shed some light on this? > > Maybe a glow of twilight. :) This check was added quite early in the new > build system and was included in the original integration of the new > build system into mainline. I remember vaguely that we had issues with > some machines with strange setups which turned out to have unexpected > symlinks. So we thought it was better to clearly show in the configure > log which compiler *really* was used. > > From the hg history, I also see that about a year ago, I added this > comment in JDK-8034788: > # FIXME: This test should not be needed anymore; we don't do that for > any platform. > > So maybe we should live up to that fixme, and remove the check. :-) > > I just realized that we can still keep ability to debug broken systems > by resolving the symlink, but just printing the result and not modifying > the path to the CC we will use. I opened > https://bugs.openjdk.java.net/browse/JDK-8148351 for this. Thanks for the feedback. I can understand why it was added. Simple verbosity at appropriate points can help debug a lot of these configuration issues. Should I go ahead and create a patch for this or are you already working on it? An AC_MSG_NOTICE or AC_MSG_WARNING seems sufficient to help debug broken systems. > > /Magnus > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From bob.vandette at oracle.com Wed Jan 27 18:37:21 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 27 Jan 2016 13:37:21 -0500 Subject: RFR: 8148302: Initial Bringup of Android in mobile/dev In-Reply-To: <56A89466.6030502@oracle.com> References: <86B4D3CB-E8ED-4857-A18E-B590C2BECB8F@oracle.com> <56A89466.6030502@oracle.com> Message-ID: <30F35B6E-2EF9-42B8-BC30-0912BA9EE882@oracle.com> Here?s the updated webrev with updates based on your feedback. http://cr.openjdk.java.net/~bobv/8148302/webrev.01 I implemented all of the changes suggested. For the X11 issue, I removed my changes and replaced BUILD_HEADLESS_ONLY with SUPPORT_HEADFUL. This allows a headless only build to be fully controlled by ?disable-headful. This shouldn?t impact our ARMv8 build since we set both ?disable-headful and BUILD_HEADLESS_ONLY. Thanks, Bob. > On Jan 27, 2016, at 4:56 AM, Magnus Ihse Bursie wrote: > > On 2016-01-26 20:50, Bob Vandette wrote: >> Please review the changes for two improvements for the Mobile Dev Forest. >> >> With these changes, the mobile/dev forest can successfully build x86 and ARM Android >> JDK 9 binaries. The ARM binaries use the Zero ARM interpreter while the x86 >> implementation uses standard x86 Hotspot VMs. >> >> The webrev also includes 1 fix for iOS BSD builds in hotspot/make/bsd/makefiles/vm.make. >> >> JDK-8148304 Mobile: iOS builds fail on assembler files >> https://bugs.openjdk.java.net/browse/JDK-8148304 >> >> JDK-8148302 Mobile: Initial bring of Android x86 and ARM >> https://bugs.openjdk.java.net/browse/JDK-8148302 >> >> Here?s the webrev: >> >> http://cr.openjdk.java.net/~bobv/8148302/webrev > > Hi Bob, > > Some comments: > > * In jni_util_md.c, you have accidentally lost a trailing ). > > * In spec.gmk.in, please use ":=" instead of "=". The former is assignment, the latter is used for macro expansion. (As a rule of thumb, := should always be used unless you have explicit reasons.) > > * In CompileJavaModules.gmk, why do you remove the exclude for BUILD_HEADLESS_ONLY? This change affects all platforms, not only android. > > * In lib-x11.m4, I *really* don't like adding X11 paths when we should not have X11! (And it's even worse since you do not check for Android but do so for all platforms.) What files are needed, and for what library? Can you not fix this dependency by removing the #include statements in the source code instead? Otherwise, I'd say that android *is* indeed dependent on X11, and you need to express this properly. > > * In lib-ffi.m4 and Copy-java.base.gmk: I think this a bit problematic. I believe what you're trying to achieve is similar to what we do for freetype, where we "bundle" the library with the resulting product. I'd rather see this libffi bundling based on that behavior. More concretely: > - The name of the variable should be like LIBFFI_BUNDLE_LIB_PATH, to clearly show that this is used only when bundling the product, not when compiling it. > - Whether to bundle or not should be determined in lib-ffi.m4. The default value should be "bundle if android+zero, otherwise not". If you want to, you can add a --enable-libffi-bundling to override this. I won't require it, but I generally find such things useful since you can test that bundling works even without building for a specific target. The code in Copy-java.base.gmk should then only test if this variable is present, compare with freetype in Copy-java.desktop. Finally, the configure code must check for the case that libffi bundling is enabled but no explicit libffi path is set (e.g. it is autodetected). It's okay to abort with an error, but it must be detected. > > And finally, a note of appreciation. :-) I'm really happy to see the ugly solution with the hard-coded linker scripts go away in flags.m4! > > /Magnus From ekrichardson at gmail.com Thu Jan 21 19:41:43 2016 From: ekrichardson at gmail.com (Eric Richardson) Date: Thu, 21 Jan 2016 11:41:43 -0800 Subject: RFR: JDK-8147795 Build system support for BSD In-Reply-To: <56A0D2B8.2040004@oracle.com> References: <569F6772.50703@oracle.com> <569F6C5C.1020007@oracle.com> <569F7853.8070400@oracle.com> <569FF95C.8060907@oracle.com> <56A0D2B8.2040004@oracle.com> Message-ID: Hi Magnus, I am just an observer here but good work. I have been on this list for a long time because of my interest in MacOSX and that port so I naturally thought that BSD would become part of mainline Java too. More platforms for Java is better. Because of your work I took a look at BSD and the history along with the birth of GNU Linux. I really didn't know what a great server platform BSD is or how much it is used. I always see Greg Lewis pulling changes into BSD and wondered why it wasn't part of the main Java repo. It appears that people must use Java but build from source. Not sure if that is just standard procedure on FreeBSD for instance. https://www.freebsd.org/java/ I guess it would only take one variant of BSD to pass the TCK - not sure if BSD was ever in the mainline. Anyway, hope you manage to get your changes accepted and you can make more progress. Eric On Thu, Jan 21, 2016 at 4:44 AM, dalibor topic wrote: > On 20.01.2016 22:17, Magnus Ihse Bursie wrote: > >> A reflection, though: If the requirement for such a >> port is that a company provides continuous testing and support, then I >> believe it's unlikely that any BSD port will ever reach the mainline, >> due to the community based nature of the BSD projects. >> > > Community supported ports have been merged into mainline in the past when > they have passed the TCK with the expectation that they are kept in shape > by the corresponding (sub)community in OpenJDK, and if they aren't, that > they'd get dropped out of mainline again. > > A JEP would be a second item to look at, of course, now that we have a JEP > process in place. > > Typically, they'd go through the JDK Release Project in development first > (i.e. JDK 9 now), and then potentially get backported to an Update release > Project. > > With respect to the BSD Port, the FreeBSD Foundation is listed here: > http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html but > I'm not sure if they have completed their respective efforts yet. > > We already have the BSD Port Project [1], sponsored by the Porters Group >> [2]. They maintain their own forests. For jdk8, the forest contains a >> number of patches for BSD. These have not been included upstream, for >> reasons I can only speculate in. >> > > I think it unfortunately came down to lack of man power among BSD Port > developers at the time when the dust after the OS X Port's integration into > JDK 8 settled. [1] > > Making it easier for the BSD port to integrate JDK 9 changes sounds fine > to me, but I'm not a JDK 9/build area Reviewer. > > cheers, > dalibor topic > > [1] > http://mail.openjdk.java.net/pipermail/bsd-port-dev/2014-April/002245.html > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > > From paul.sandoz at oracle.com Wed Jan 27 16:31:21 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 Jan 2016 17:31:21 +0100 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56A8CC64.3080500@oracle.com> References: <56A8CC64.3080500@oracle.com> Message-ID: <7E17DDBD-9795-49FA-B83B-DF0F93C13374@oracle.com> I think it quite reasonable to push everything to jdk9/dev. Paul. > On 27 Jan 2016, at 14:55, Aleksey Shipilev wrote: > > Hi again, > > This is a formal pre-integration review thread for JEP 280 ("Indify > String Concatenation") integration: > http://openjdk.java.net/jeps/280 > > The JEP is Targeted, the CCC is approved, the code reviews and > pre-integration checks are clean. > > Code changes are happening simultaneously in four components: > > a) (M) javac changes that emit indy: > http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ > > b) (L) JDK changes with StringConcatFactory and friends, plus fixing > the regression tests that do not expect additional indys: > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ > > c) (XS) Build changes that force emitting the "legacy" inline > StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is > expected): > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ > > d) (XS) HotSpot changes that fix a GC regression test that now > allocates some metaspace from within the test methods having a string > concatenation: > http://cr.openjdk.java.net/~shade/8085796/webrev.hs.00/ > > These changes were already reviewed by multiple people, and so I would > like to keep the comments only for serious breaking issues at this > point. (Note that this thread cross-posts over several mailing lists: > bike-shedding discussion would get multiplied a lot!) > > Formal acknowledgements from Reviewers would be appreciated. Pending no > show-stopper comments, I'd like to push this through jdk9/dev in 24 hours. > > Thanks, > -Aleksey > From magnus.ihse.bursie at oracle.com Wed Jan 27 19:58:49 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Jan 2016 20:58:49 +0100 Subject: RFR: 8148302: Initial Bringup of Android in mobile/dev In-Reply-To: References: <86B4D3CB-E8ED-4857-A18E-B590C2BECB8F@oracle.com> <56A89466.6030502@oracle.com> Message-ID: <56A92179.7000306@oracle.com> On 2016-01-27 17:15, Bob Vandette wrote: >> On Jan 27, 2016, at 4:56 AM, Magnus Ihse Bursie wrote: >> >> On 2016-01-26 20:50, Bob Vandette wrote: >>> Please review the changes for two improvements for the Mobile Dev Forest. >>> >>> With these changes, the mobile/dev forest can successfully build x86 and ARM Android >>> JDK 9 binaries. The ARM binaries use the Zero ARM interpreter while the x86 >>> implementation uses standard x86 Hotspot VMs. >>> >>> The webrev also includes 1 fix for iOS BSD builds in hotspot/make/bsd/makefiles/vm.make. >>> >>> JDK-8148304 Mobile: iOS builds fail on assembler files >>> https://bugs.openjdk.java.net/browse/JDK-8148304 >>> >>> JDK-8148302 Mobile: Initial bring of Android x86 and ARM >>> https://bugs.openjdk.java.net/browse/JDK-8148302 >>> >>> Here?s the webrev: >>> >>> http://cr.openjdk.java.net/~bobv/8148302/webrev >> Hi Bob, >> >> Some comments: >> >> * In jni_util_md.c, you have accidentally lost a trailing ). > Thanks for catching that. Fixed. > >> * In spec.gmk.in, please use ":=" instead of "=". The former is assignment, the latter is used for macro expansion. (As a rule of thumb, := should always be used unless you have explicit reasons.) > Fixed. >> * In CompileJavaModules.gmk, why do you remove the exclude for BUILD_HEADLESS_ONLY? This change affects all platforms, not only android. > I don?t believe BUILD_HEADLESS_ONLY works for any platform without this fix. Although I specify ?disable-headful and set BUILD_HEADLESS_ONLY, > the desktop module is still built and fails compiling several files due to these missing classes. > > * For target java.desktop: > /export/users/bobv/mobile-dev/jdk/src/java.desktop/share/classes/sun/awt/www/content/audio/aiff.java:34: error: package sun.applet does not exist > import sun.applet.AppletAudioClip; > ^ > /export/users/bobv/mobile-dev/jdk/src/java.desktop/share/classes/sun/awt/www/content/audio/basic.java:34: error: package sun.applet does not exist > import sun.applet.AppletAudioClip; > > /export/users/bobv/mobile-dev/jdk/src/java.desktop/share/classes/sun/awt/www/content/audio/wav.java:34: error: package sun.applet does not exist > import sun.applet.AppletAudioClip; > ^ > /export/users/bobv/mobile-dev/jdk/src/java.desktop/share/classes/sun/awt/www/content/audio/x_aiff.java:34: error: package sun.applet does not exist > import sun.applet.AppletAudioClip; > ^ > /export/users/bobv/mobile-dev/jdk/src/java.desktop/share/classes/sun/awt/www/content/audio/x_wav.java:34: error: package sun.applet does not exist > import sun.applet.AppletAudioClip; > ^ > /export/users/bobv/mobile-dev/jdk/src/java.desktop/share/classes/sun/font/SunFontManager.java:2843: error: package sun.applet does not exist > return sm instanceof sun.applet.AppletSecurity; > >> * In lib-x11.m4, I *really* don't like adding X11 paths when we should not have X11! (And it's even worse since you do not check for Android but do so for all platforms.) What files are needed, and for what library? Can you not fix this dependency by removing the #include statements in the source code instead? Otherwise, I'd say that android *is* indeed dependent on X11, and you need to express this properly. > I removed this change. It?s no longer necessary. > > The change that most likely fixed this is the setting of BUILD_HEADLESS_ONLY. > > Shouldn?t BUILD_HEADLESS_ONLY be set when ?disable-headful is set to true or maybe the uses of BUILD_HEADLESS_ONLY > should be changed to SUPPORT_HEADFUL? Yeah, the headless stuff is quite messy. :-( We've never really gotten around to cleaning it up. It seems you are right, we have a lot of tests for BUILD_HEADLESS_ONLY but never sets it (!). That does not make sense. I think part of the confusion here is the lack of good terms. While "headless" is an accepted term, it's not really of any use to use since we *always* build the "headless" libraries. So the only thing that we can turn on and off is the "headful" form. But that's not really an accepted term. And adding adjectives like "only" does not do wonders for good names, even if it's technically correct. As for defining BUILD_HEADLESS_ONLY, we really try to avoid making a difference just by checking for lack of definition, instead we assign "true" or "false" to a variable. I think this lack of a clear good name to use to select that which is relevant for us has held back an overhaul of this area. In short, if you have a good suggestion of a variable name to use, I'd be more than happy to clean this mess up. :-) /Magnus > > >> * In lib-ffi.m4 and Copy-java.base.gmk: I think this a bit problematic. I believe what you're trying to achieve is similar to what we do for freetype, where we "bundle" the library with the resulting product. I'd rather see this libffi bundling based on that behavior. More concretely: >> - The name of the variable should be like LIBFFI_BUNDLE_LIB_PATH, to clearly show that this is used only when bundling the product, not when compiling it. > Ok. >> - Whether to bundle or not should be determined in lib-ffi.m4. The default value should be "bundle if android+zero, otherwise not". If you want to, you can add a --enable-libffi-bundling to override this. I won't require it, but I generally find such things useful since you can test that bundling works even without building for a specific target. The code in Copy-java.base.gmk should then only test if this variable is present, compare with freetype in Copy-java.desktop. Finally, the configure code must check for the case that libffi bundling is enabled but no explicit libffi path is set (e.g. it is autodetected). It's okay to abort with an error, but it must be detected. > Yes, I was trying to model this after the freetype library. > > Ok, I?ll make that change. > > >> And finally, a note of appreciation. :-) I'm really happy to see the ugly solution with the hard-coded linker scripts go away in flags.m4! > They are also removed from the VM makefiles. > > I?m happy that we don?t need this anymore. This happened when we started generating devkits from the Android NDK. > The NDK toolchain generation script generates toolchains that handle the ldscripts for us. > > Thanks for the review, > Bob. > >> /Magnus From magnus.ihse.bursie at oracle.com Wed Jan 27 20:02:31 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Jan 2016 21:02:31 +0100 Subject: RFR: 8148302: Initial Bringup of Android in mobile/dev In-Reply-To: <30F35B6E-2EF9-42B8-BC30-0912BA9EE882@oracle.com> References: <86B4D3CB-E8ED-4857-A18E-B590C2BECB8F@oracle.com> <56A89466.6030502@oracle.com> <30F35B6E-2EF9-42B8-BC30-0912BA9EE882@oracle.com> Message-ID: <56A92257.6040701@oracle.com> On 2016-01-27 19:37, Bob Vandette wrote: > Here?s the updated webrev with updates based on your feedback. > > http://cr.openjdk.java.net/~bobv/8148302/webrev.01 > > I implemented all of the changes suggested. > > For the X11 issue, I removed my changes and replaced BUILD_HEADLESS_ONLY with > SUPPORT_HEADFUL. This allows a headless only build to be fully controlled by > ?disable-headful. This shouldn?t impact our ARMv8 build since we set both ?disable-headful > and BUILD_HEADLESS_ONLY. Ah, right, you started cleaning up the mess already. :) That's nice, SUPPORT_HEADFUL==yes is at least expressing the right kind of semantics. The new webrev looks good to me. Thank you Bob for helping keeping the quality of the build system code high! /Magnus > > Thanks, > Bob. > > >> On Jan 27, 2016, at 4:56 AM, Magnus Ihse Bursie wrote: >> >> On 2016-01-26 20:50, Bob Vandette wrote: >>> Please review the changes for two improvements for the Mobile Dev Forest. >>> >>> With these changes, the mobile/dev forest can successfully build x86 and ARM Android >>> JDK 9 binaries. The ARM binaries use the Zero ARM interpreter while the x86 >>> implementation uses standard x86 Hotspot VMs. >>> >>> The webrev also includes 1 fix for iOS BSD builds in hotspot/make/bsd/makefiles/vm.make. >>> >>> JDK-8148304 Mobile: iOS builds fail on assembler files >>> https://bugs.openjdk.java.net/browse/JDK-8148304 >>> >>> JDK-8148302 Mobile: Initial bring of Android x86 and ARM >>> https://bugs.openjdk.java.net/browse/JDK-8148302 >>> >>> Here?s the webrev: >>> >>> http://cr.openjdk.java.net/~bobv/8148302/webrev >> Hi Bob, >> >> Some comments: >> >> * In jni_util_md.c, you have accidentally lost a trailing ). >> >> * In spec.gmk.in, please use ":=" instead of "=". The former is assignment, the latter is used for macro expansion. (As a rule of thumb, := should always be used unless you have explicit reasons.) >> >> * In CompileJavaModules.gmk, why do you remove the exclude for BUILD_HEADLESS_ONLY? This change affects all platforms, not only android. >> >> * In lib-x11.m4, I *really* don't like adding X11 paths when we should not have X11! (And it's even worse since you do not check for Android but do so for all platforms.) What files are needed, and for what library? Can you not fix this dependency by removing the #include statements in the source code instead? Otherwise, I'd say that android *is* indeed dependent on X11, and you need to express this properly. >> >> * In lib-ffi.m4 and Copy-java.base.gmk: I think this a bit problematic. I believe what you're trying to achieve is similar to what we do for freetype, where we "bundle" the library with the resulting product. I'd rather see this libffi bundling based on that behavior. More concretely: >> - The name of the variable should be like LIBFFI_BUNDLE_LIB_PATH, to clearly show that this is used only when bundling the product, not when compiling it. >> - Whether to bundle or not should be determined in lib-ffi.m4. The default value should be "bundle if android+zero, otherwise not". If you want to, you can add a --enable-libffi-bundling to override this. I won't require it, but I generally find such things useful since you can test that bundling works even without building for a specific target. The code in Copy-java.base.gmk should then only test if this variable is present, compare with freetype in Copy-java.desktop. Finally, the configure code must check for the case that libffi bundling is enabled but no explicit libffi path is set (e.g. it is autodetected). It's okay to abort with an error, but it must be detected. >> >> And finally, a note of appreciation. :-) I'm really happy to see the ugly solution with the hard-coded linker scripts go away in flags.m4! >> >> /Magnus From magnus.ihse.bursie at oracle.com Wed Jan 27 20:04:44 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Jan 2016 21:04:44 +0100 Subject: [rfc] Avoid failure when compiler is wrapped. In-Reply-To: <56A8F645.8030501@redhat.com> References: <56A22417.4080008@redhat.com> <325639192.12248921.1453754338848.JavaMail.zimbra@redhat.com> <56A89751.6030300@oracle.com> <56A8F645.8030501@redhat.com> Message-ID: <56A922DC.3020002@oracle.com> On 2016-01-27 17:54, Jiri Vanek wrote: > On 01/27/2016 11:09 AM, Magnus Ihse Bursie wrote: >> On 2016-01-25 21:38, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> Hello! >>>> >>>> When compiler is wrapped, the configure phase of build fails: >>>> >>>> [...] >>>> checking for gcc... /usr/lib64/cscppc/gcc >>>> configure: Resolving CC (as /usr/lib64/cscppc/gcc) failed, using >>>> /usr/lib64/cscppc/gcc directly. >>>> checking resolved symbolic links for CC... /usr/bin/cscppc >>>> checking if CC is disguised ccache... no, keeping CC >>>> configure: The C compiler (located as /usr/bin/cscppc) does not >>>> seem to be >>>> the required GCC compiler. >>>> configure: The result from running with --version was: "Usage:" >>>> configure: error: GCC compiler is required. Try setting >>>> --with-tools-dir. >>>> configure exiting with result code 1 >>>> >>>> >>>> From time to time I'm building RPMS for fedora with wrapped >>>> compiler to be >>>> able to investigate C >>>> code changes. Added is patch, which is allowing to walk around the >>>> issue. >>>> >>>> I'm wondering if this is still desired behaviour. or if it can be >>>> better >>>> iff-ed out to be by default >>>> on, but eg only disablef on AIX. >>>> >>>> CCed is Andrew, who is facing similar issue on Gentoo. >>>> >>>> >>>> Thanx! >>>> J. >>>> >>> The Gentoo issue was different; it's related to distcc failing the >>> version >>> test, rather than symlink issues. >>> >>> I think this block should be removed, not just comment out, if not >>> needed. >>> But first, I think we need to know why the dereferencing is there. >>> Can someone at Oracle shed some light on this? >> >> Maybe a glow of twilight. :) This check was added quite early in the >> new build system and was >> included in the original integration of the new build system into >> mainline. I remember vaguely that >> we had issues with some machines with strange setups which turned out >> to have unexpected symlinks. >> So we thought it was better to clearly show in the configure log >> which compiler *really* was used. >> >> From the hg history, I also see that about a year ago, I added this >> comment in JDK-8034788: >> # FIXME: This test should not be needed anymore; we don't do that >> for any platform. >> >> So maybe we should live up to that fixme, and remove the check. :-) >> >> I just realized that we can still keep ability to debug broken >> systems by resolving the symlink, but >> just printing the result and not modifying the path to the CC we will >> use. I opened >> https://bugs.openjdk.java.net/browse/JDK-8148351 for this. >> > Thank you for this Magnus. I will try to prepare regualr webrev based > on your suggestion. If you fix it in meantime, just let us know :) I posted "RFR: JDK-8148351 Only display resolved symlink for compiler, do not change path" to this list shortly after my previous comment to you. /Magnus > > > Thanx! > > J > From magnus.ihse.bursie at oracle.com Wed Jan 27 22:40:43 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Jan 2016 23:40:43 +0100 Subject: RFR: JDK-8148416 Fix merge error in hotspot.m4 introduced in Merge changeset 8b46c6cecc37 Message-ID: <56A9476B.9060407@oracle.com> A merge error occured in changeset 8b46c6cecc37 in the file hotspot.m4. Bug: https://bugs.openjdk.java.net/browse/JDK-8148416 Patch inline: diff --git a/common/autoconf/hotspot.m4 b/common/autoconf/hotspot.m4 --- a/common/autoconf/hotspot.m4 +++ b/common/autoconf/hotspot.m4 @@ -266,14 +266,3 @@ HOTSPOT_MAKE_ARGS="$HOTSPOT_TARGET" AC_SUBST(HOTSPOT_MAKE_ARGS) ]) - - # -g is already added by ENABLE_DEBUG_SYMBOLS and the hotspot makefiles - # will basically do slowdebug builds when DEBUG_BINARIES is set for - # fastdebug builds - DEBUG_BINARIES=false - # Fastdebug builds with this setting will essentially be slowdebug - # in hotspot. - # -g is already added by ENABLE_DEBUG_SYMBOLS and the hotspot makefiles - # will basically do slowdebug builds when DEBUG_BINARIES is set for - # fastdebug builds - DEBUG_BINARIES=false \ No newline at end of file /Magnus From david.holmes at oracle.com Thu Jan 28 05:49:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Jan 2016 15:49:30 +1000 Subject: RFR: JDK-8148416 Fix merge error in hotspot.m4 introduced in Merge changeset 8b46c6cecc37 In-Reply-To: <56A9476B.9060407@oracle.com> References: <56A9476B.9060407@oracle.com> Message-ID: <56A9ABEA.4080607@oracle.com> On 28/01/2016 8:40 AM, Magnus Ihse Bursie wrote: > A merge error occured in changeset 8b46c6cecc37 in the file hotspot.m4. Very odd given the file was brand new prior to the merge. > Bug: https://bugs.openjdk.java.net/browse/JDK-8148416 > Patch inline: > > diff --git a/common/autoconf/hotspot.m4 b/common/autoconf/hotspot.m4 > --- a/common/autoconf/hotspot.m4 > +++ b/common/autoconf/hotspot.m4 > @@ -266,14 +266,3 @@ > HOTSPOT_MAKE_ARGS="$HOTSPOT_TARGET" > AC_SUBST(HOTSPOT_MAKE_ARGS) > ]) > - > - # -g is already added by ENABLE_DEBUG_SYMBOLS and the hotspot > makefiles > - # will basically do slowdebug builds when DEBUG_BINARIES is set for > - # fastdebug builds > - DEBUG_BINARIES=false > - # Fastdebug builds with this setting will essentially be slowdebug > - # in hotspot. > - # -g is already added by ENABLE_DEBUG_SYMBOLS and the hotspot > makefiles > - # will basically do slowdebug builds when DEBUG_BINARIES is set for > - # fastdebug builds > - DEBUG_BINARIES=false > \ No newline at end of file Looks good. Thanks, David > /Magnus > From magnus.ihse.bursie at oracle.com Thu Jan 28 06:57:23 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 28 Jan 2016 07:57:23 +0100 Subject: RFR: JDK-8148416 Fix merge error in hotspot.m4 introduced in Merge changeset 8b46c6cecc37 In-Reply-To: <56A9ABEA.4080607@oracle.com> References: <56A9476B.9060407@oracle.com> <56A9ABEA.4080607@oracle.com> Message-ID: <56A9BBD3.10306@oracle.com> On 2016-01-28 06:49, David Holmes wrote: > On 28/01/2016 8:40 AM, Magnus Ihse Bursie wrote: >> A merge error occured in changeset 8b46c6cecc37 in the file hotspot.m4. > > Very odd given the file was brand new prior to the merge. I split out half the contents of the jdk-options.m4 into the new file hotspot.m4. As usual, I used "hg cp" to do this, so changes in the "old" jdk-options.m4 that relate to code that now resides in hotspot.m4 can be tracked correctly. This normally works fine, but from time to time, I've noticed that mercurial can get confused and suggest weird merges. > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8148416 >> Patch inline: >> >> diff --git a/common/autoconf/hotspot.m4 b/common/autoconf/hotspot.m4 >> --- a/common/autoconf/hotspot.m4 >> +++ b/common/autoconf/hotspot.m4 >> @@ -266,14 +266,3 @@ >> HOTSPOT_MAKE_ARGS="$HOTSPOT_TARGET" >> AC_SUBST(HOTSPOT_MAKE_ARGS) >> ]) >> - >> - # -g is already added by ENABLE_DEBUG_SYMBOLS and the hotspot >> makefiles >> - # will basically do slowdebug builds when DEBUG_BINARIES is set for >> - # fastdebug builds >> - DEBUG_BINARIES=false >> - # Fastdebug builds with this setting will essentially be slowdebug >> - # in hotspot. >> - # -g is already added by ENABLE_DEBUG_SYMBOLS and the hotspot >> makefiles >> - # will basically do slowdebug builds when DEBUG_BINARIES is set for >> - # fastdebug builds >> - DEBUG_BINARIES=false >> \ No newline at end of file > > Looks good. Thanks. /Magnus > > Thanks, > David > >> /Magnus >> From maurizio.cimadamore at oracle.com Thu Jan 28 16:34:36 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Jan 2016 16:34:36 +0000 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56A8CC64.3080500@oracle.com> References: <56A8CC64.3080500@oracle.com> Message-ID: <56AA431C.4010008@oracle.com> Langtools changes look fine to me (as discussed on previous review thread). Thanks! Maurizio On 27/01/16 13:55, Aleksey Shipilev wrote: > Hi again, > > This is a formal pre-integration review thread for JEP 280 ("Indify > String Concatenation") integration: > http://openjdk.java.net/jeps/280 > > The JEP is Targeted, the CCC is approved, the code reviews and > pre-integration checks are clean. > > Code changes are happening simultaneously in four components: > > a) (M) javac changes that emit indy: > http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ > > b) (L) JDK changes with StringConcatFactory and friends, plus fixing > the regression tests that do not expect additional indys: > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ > > c) (XS) Build changes that force emitting the "legacy" inline > StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is > expected): > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ > > d) (XS) HotSpot changes that fix a GC regression test that now > allocates some metaspace from within the test methods having a string > concatenation: > http://cr.openjdk.java.net/~shade/8085796/webrev.hs.00/ > > These changes were already reviewed by multiple people, and so I would > like to keep the comments only for serious breaking issues at this > point. (Note that this thread cross-posts over several mailing lists: > bike-shedding discussion would get multiplied a lot!) > > Formal acknowledgements from Reviewers would be appreciated. Pending no > show-stopper comments, I'd like to push this through jdk9/dev in 24 hours. > > Thanks, > -Aleksey > From erik.joelsson at oracle.com Fri Jan 29 13:18:13 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 Jan 2016 14:18:13 +0100 Subject: question on jigsaw build In-Reply-To: <56A61869.2020802@oracle.com> References: <56A61869.2020802@oracle.com> Message-ID: <56AB6695.3070801@oracle.com> Hello, There are no plans in this area but we are certainly open for suggestions. Generating IDE project files is definitely something we want to support. We just haven't gotten to it yet. The removal of ALL_SRC_DIRS was for code simplification in the makefiles and because javac has changed the way it wants the source roots specified in jake. I did not realize there was an external dependency on this construct. /Erik On 2016-01-25 13:43, Maurizio Cimadamore wrote: > Hi, > the current build system in JDK 9 has a way to recover all the source > dirs for a given module, by doing something like this: > > $(call ALL_SRC_DIRS,$(mod)) > > That is, the build system exports a function that can be passed a > module name and will return all the source roots for the module with > that name. > > This is an extremely helpful piece of functionality when building > things like IDE support - as one can leverage the knowledge of the > build system in order to put together an IDE projects with the right > paths in it, regardless of the OS and ARCH (details which are all > taken care of by the build itself). > > I see that this functionality is now removed from the current jigsaw > build - which instead declares a sequence of (dynamically defined) > targets to compile a module with name xyz; as a result, the variables > containing the source roots for xyz are not exported anymore, thus > severely impacting usability from 3rd party build tools. > > What is the plan in this direction? Is there any talks about having > the build system export a pseudo API for querying variables (source > roots, generated sources, output dirs) for a given module w/o > compiling them? > > Thanks > Maurizio From erik.joelsson at oracle.com Fri Jan 29 13:21:46 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 Jan 2016 14:21:46 +0100 Subject: RFR: JDK-8148120 Incremental update from build-infra project In-Reply-To: <56A6287D.1020408@oracle.com> References: <56A491CC.4010409@oracle.com> <56A5D924.1080902@oracle.com> <56A6287D.1020408@oracle.com> Message-ID: <56AB676A.5050704@oracle.com> Looks ok. /Erik On 2016-01-25 14:51, Magnus Ihse Bursie wrote: > On 2016-01-25 09:13, Erik Joelsson wrote: >> In NativeCompilation.gmk, the exit value saving for linking is most >> likely redundant. I managed to remove that for the compile command >> lines. There I verified that failed compiles still failed the build, >> without the need for exitvalue saving. I do believe this was relying >> on the -e switch to bash (I tried both with and without that and >> pipefail to be sure which was required), but we do have that always >> on windows. > > Aha, nice. I based the new link code on the old compile-call version, > and when I merged in your new updates I didn't realize that the code I > based it on had been simplified. > > Updated webrev: (only NativeCompilation.gmk changed) > http://cr.openjdk.java.net/~ihse/JDK-8148120-incremental-updates-from-build-infra/webrev.02 > > > /Magnus > >> >> /Erik >> >> On 2016-01-24 09:56, Magnus Ihse Bursie wrote: >>> This patch contains a series of small fixes of general applicability >>> that have been created in the build-infra project. These are: >>> >>> * Add missing llvm library dependency >>> * Improve compare script for static libraries >>> * Simplify LogFailures interface, and add support for storing >>> command lines >>> * Hide "Creating library *.lib and object *.exp" text when linking >>> on Windows >>> * Fix problems with smartjavac when using the build-compare >>> functionality >>> * When repeating output, truncate it if too long >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148120 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8148120-incremental-updates-from-build-infra/webrev.01 >>> >>> /Magnus >>> >> > From erik.joelsson at oracle.com Fri Jan 29 13:27:35 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 Jan 2016 14:27:35 +0100 Subject: RFR: JDK-8148351 Only display resolved symlink for compiler, do not change path In-Reply-To: <56A89CBF.9080403@oracle.com> References: <56A89CBF.9080403@oracle.com> Message-ID: <56AB68C7.8070608@oracle.com> Looks good. /Erik On 2016-01-27 11:32, Magnus Ihse Bursie wrote: > During toolchain detection, if the found compiler (CC or CXX) is a > symbolic link, we resolve it and point to the resolved binary. This > was introduced to be able to debug systems with a broken setup, but it > breaks use cases were a CC wrapper is used. > > A better solution is to just print the path of the resolved symlink > and keep the original value intact. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148351 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8148351-do-not-replace-compiler-symlink/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Fri Jan 29 13:32:06 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 Jan 2016 14:32:06 +0100 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56A8CC64.3080500@oracle.com> References: <56A8CC64.3080500@oracle.com> Message-ID: <56AB69D6.7060801@oracle.com> On 2016-01-27 14:55, Aleksey Shipilev wrote: > c) (XS) Build changes that force emitting the "legacy" inline > StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is > expected): > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ In what context do we need pre-JDK 9 bytecode for java.base and jdk.compiler? /Erik From aleksey.shipilev at oracle.com Fri Jan 29 13:51:39 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 29 Jan 2016 16:51:39 +0300 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56AB69D6.7060801@oracle.com> References: <56A8CC64.3080500@oracle.com> <56AB69D6.7060801@oracle.com> Message-ID: <56AB6E6B.2000103@oracle.com> (dropping corelibs-dev and hotspot-dev) On 01/29/2016 04:32 PM, Erik Joelsson wrote: > On 2016-01-27 14:55, Aleksey Shipilev wrote: >> c) (XS) Build changes that force emitting the "legacy" inline >> StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is >> expected): >> http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ > In what context do we need pre-JDK 9 bytecode for java.base and > jdk.compiler? Circularity issues, one critical and one manageable. Critical: java.base is excepted to let JDK bootstrap properly, otherwise processing a String concat expression within the j.l.invoke infrastructure that handles ISC would fail because of the circularity. Manageable: jdk.compiler is excepted to test the rest of JDK properly first. The bug in ISC that breaks a compiler would introduce breakages in many things that are compiled with it, sometimes during the compilation itself. Which, in best case, fails some limited amount of regression tests, but frequently fails the OpenJDK build itself. We may want to reconsider this going forward, after ISC stabilizes: https://bugs.openjdk.java.net/browse/JDK-8148605 Cheers, -Aleksey From sundararajan.athijegannathan at oracle.com Fri Jan 29 16:13:54 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 29 Jan 2016 21:43:54 +0530 Subject: RFR 8148617: top level make docs target does not generate javadocs for dynalink API Message-ID: <56AB8FC2.4070803@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8148617/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8148617 Dynalink API is specified by JEP-276 (http://openjdk.java.net/jeps/276). The current change is just to add the missing makefile instructions to generate javadoc. Thanks, -Sundar From erik.joelsson at oracle.com Fri Jan 29 16:22:29 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 Jan 2016 17:22:29 +0100 Subject: RFR 8148617: top level make docs target does not generate javadocs for dynalink API In-Reply-To: <56AB8FC2.4070803@oracle.com> References: <56AB8FC2.4070803@oracle.com> Message-ID: <56AB91C5.1060107@oracle.com> Looks good. /Erik On 2016-01-29 17:13, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8148617/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8148617 > > Dynalink API is specified by JEP-276 > (http://openjdk.java.net/jeps/276). The current change is just to add > the missing makefile instructions to generate javadoc. > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Fri Jan 29 16:23:55 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 29 Jan 2016 17:23:55 +0100 Subject: RFR 8148617: top level make docs target does not generate javadocs for dynalink API In-Reply-To: <56AB8FC2.4070803@oracle.com> References: <56AB8FC2.4070803@oracle.com> Message-ID: <56AB921B.1080200@oracle.com> Looks good. Hannes Am 2016-01-29 um 17:13 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8148617/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8148617 > > Dynalink API is specified by JEP-276 > (http://openjdk.java.net/jeps/276). The current change is just to add > the missing makefile instructions to generate javadoc. > > Thanks, > -Sundar From erik.joelsson at oracle.com Fri Jan 29 17:04:24 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 Jan 2016 18:04:24 +0100 Subject: RFR(M) 8069540: Remove universal binaries support from hotspot build In-Reply-To: References: Message-ID: <56AB9B98.9000403@oracle.com> (adding build-dev) Looks good enough to me. /Erik On 2016-01-29 17:51, Gerard Ziemski wrote: > Hi all (and especially the makefiles experts), > > This fix removes support for building hotspot universal libraries on Mac OS X and simplifies the makefiles. > > We are still building Mac OS X hotspot libraries as universal libraries, but with only one architecture (x86_64). The rest of JDK is built as plain single architecture libraries and there is no longer any need for this complexity (since we haven't supported 32bit platform on Mac OS X for a while now) > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8069540 > Webrev: http://cr.openjdk.java.net/~gziemski/8069540_jdk_rev2/ > Webrev: http://cr.openjdk.java.net/~gziemski/8069540_hotspot_rev2/ > > Testing: JPRT + RBT on all platforms. > > > cheers From sundararajan.athijegannathan at oracle.com Fri Jan 29 17:11:00 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 29 Jan 2016 22:41:00 +0530 Subject: RFR 8148617: top level make docs target does not generate javadocs for dynalink API In-Reply-To: <56AB921B.1080200@oracle.com> References: <56AB8FC2.4070803@oracle.com> <56AB921B.1080200@oracle.com> Message-ID: <56AB9D24.7030203@oracle.com> Added newline before line 1270 in Javadoc.gmk. Updated webrev: http://cr.openjdk.java.net/~sundar/8148617/webrev.01/ -Sundar On 1/29/2016 9:53 PM, Hannes Wallnoefer wrote: > Looks good. > > Hannes > > > Am 2016-01-29 um 17:13 schrieb Sundararajan Athijegannathan: >> Please review http://cr.openjdk.java.net/~sundar/8148617/webrev.00/ >> for https://bugs.openjdk.java.net/browse/JDK-8148617 >> >> Dynalink API is specified by JEP-276 >> (http://openjdk.java.net/jeps/276). The current change is just to add >> the missing makefile instructions to generate javadoc. >> >> Thanks, >> -Sundar > From erik.joelsson at oracle.com Fri Jan 29 18:50:54 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 Jan 2016 19:50:54 +0100 Subject: RFR 8148617: top level make docs target does not generate javadocs for dynalink API In-Reply-To: <56AB9D24.7030203@oracle.com> References: <56AB8FC2.4070803@oracle.com> <56AB921B.1080200@oracle.com> <56AB9D24.7030203@oracle.com> Message-ID: <56ABB48E.5060409@oracle.com> Looks good. Erik On 2016-01-29 18:11, Sundararajan Athijegannathan wrote: > Added newline before line 1270 in Javadoc.gmk. > > Updated webrev: http://cr.openjdk.java.net/~sundar/8148617/webrev.01/ > > -Sundar > > On 1/29/2016 9:53 PM, Hannes Wallnoefer wrote: >> Looks good. >> >> Hannes >> >> >> Am 2016-01-29 um 17:13 schrieb Sundararajan Athijegannathan: >>> Please review http://cr.openjdk.java.net/~sundar/8148617/webrev.00/ >>> for https://bugs.openjdk.java.net/browse/JDK-8148617 >>> >>> Dynalink API is specified by JEP-276 >>> (http://openjdk.java.net/jeps/276). The current change is just to >>> add the missing makefile instructions to generate javadoc. >>> >>> Thanks, >>> -Sundar >> > From hannes.wallnoefer at oracle.com Fri Jan 29 19:04:25 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 29 Jan 2016 20:04:25 +0100 Subject: RFR 8148617: top level make docs target does not generate javadocs for dynalink API In-Reply-To: <56AB9D24.7030203@oracle.com> References: <56AB8FC2.4070803@oracle.com> <56AB921B.1080200@oracle.com> <56AB9D24.7030203@oracle.com> Message-ID: <56ABB7B9.8000005@oracle.com> +1 Am 2016-01-29 um 18:11 schrieb Sundararajan Athijegannathan: > Added newline before line 1270 in Javadoc.gmk. > > Updated webrev: http://cr.openjdk.java.net/~sundar/8148617/webrev.01/ > > -Sundar > > On 1/29/2016 9:53 PM, Hannes Wallnoefer wrote: >> Looks good. >> >> Hannes >> >> >> Am 2016-01-29 um 17:13 schrieb Sundararajan Athijegannathan: >>> Please review http://cr.openjdk.java.net/~sundar/8148617/webrev.00/ >>> for https://bugs.openjdk.java.net/browse/JDK-8148617 >>> >>> Dynalink API is specified by JEP-276 >>> (http://openjdk.java.net/jeps/276). The current change is just to >>> add the missing makefile instructions to generate javadoc. >>> >>> Thanks, >>> -Sundar >> > From magnus.ihse.bursie at oracle.com Sat Jan 30 10:27:24 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 30 Jan 2016 11:27:24 +0100 Subject: RFR: JDK-8148655 LOG=cmdlines and other build-infra fixes Message-ID: <56AC900C.1040205@oracle.com> This is yet another collection of fixes from the build-infra hotspot project forest that has a stand-alone value. The most important change is the support of a new log option, cmdlines. This is, like the old "nofile", an option that can be added to a log level, e.g. "LOG=info,cmdlines" or used standalone "LOG=cmdlines" (in which case the log level stays at default). With this in place, the command line of "important" commands are printed. Examples of "important" commands are compiler and linker calls. Examples of "non-important" commands are "mkdir" or "cat". Note that at this point, not all "important" calls are identified, typically in esoteric stuff like gensrc. Apart from this, a few other changes are also included: * Allow DEBUG_SYMBOLS to be individually turned off (follow up to JDK-8145596) * Support .S assembly files * Expose USERNAME outside configure * Fix broken indentation Bug: https://bugs.openjdk.java.net/browse/JDK-8148655 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8148655-LOG-cmdlines-and-misc-fixes/webrev.01 /Magnus