From tim.bell at oracle.com Fri Feb 1 05:36:35 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 31 Jan 2013 21:36:35 -0800 Subject: RFR: 8006808 mapfile use check in jdk/make/common/shared/Defs-solaris.gmk is throwing 'egrep: syntax error' Message-ID: <510B5463.2050703@oracle.com> Hello http://bugs.sun.com/view_bug.do?bug_id=8006808 This check only worked as intended on Solaris/SPARC. For non-SPARC architecture, egrep throws "egrep: syntax error" and the mapfile check is skipped. The solution is to provide a search pattern in the else that is acceptable to egrep: http://cr.openjdk.java.net/~tbell/8006808/00/ Thanks in advance for any feedback. Tim From david.holmes at oracle.com Fri Feb 1 06:08:12 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Feb 2013 16:08:12 +1000 Subject: Questionable new-build failure In-Reply-To: <4E652F10-BE86-4DC8-8AA5-1414E6BDB043@oracle.com> References: <0CD3B4D3-44A6-4FCF-82C9-C4D47142400F@oracle.com> <5101BD14.8040903@oracle.com> <4D1C915D-7C99-42A0-AAE2-33C8BD62931B@oracle.com> <4E652F10-BE86-4DC8-8AA5-1414E6BDB043@oracle.com> Message-ID: <510B5BCC.4060000@oracle.com> I'm confused about this issue. My initial take was that this was caused by 8004151 because the files in the repo were not sorted, while the generated file was. Based on the changeset: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/57d5d9544628 I see: + $(GENSRC_X11WRAPPERS_TMP)/sizer.$*.exe | $(SORT) > $@.tmp but this: +long 4 +int 4 +short 2 +ptr 4 +Bool 4 +Atom 4 +Window 4 +XExtData.number 0 ... does not appear sorted to me. David H. ------- On 29/01/2013 6:41 AM, David Chase wrote: > > On 2013-01-25, at 4:55 PM, Kelly O'Hair wrote: > >> Please file JBS Issues. > > So this is a new bug that needs filing? I think it's sort of a duplicate, see below. > >> And keep in mind every "Solaris 10" system could be different. > > Solaris 10 10/09 s10x_u8wos_08a X86 > Builds with jdk8, fails with jdk7. > > I am pretty sure that the cause of the bug is a dependence (in WrapperGenerator) on the order in which items are iterated out of a hash table. That appears to have changed in the transition from jdk7 to jdk8. That change was apparently necessary to make it (very much) harder to DOS a hashtable with collisions. I observed different output running WrapperGenerator with the exact same inputs under 7 and 8, cutting and pasting from a build and replacing only the target directory and the host VM. > > It seems to be fixed in jdk8-build as of six days ago (I checked), as a side-effect of fixing 8004151 > > David > From david.holmes at oracle.com Fri Feb 1 06:55:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Feb 2013 16:55:21 +1000 Subject: RFR: 8006808 mapfile use check in jdk/make/common/shared/Defs-solaris.gmk is throwing 'egrep: syntax error' In-Reply-To: <510B5463.2050703@oracle.com> References: <510B5463.2050703@oracle.com> Message-ID: <510B66D9.1020903@oracle.com> Looks good to me Tim! David On 1/02/2013 3:36 PM, Tim Bell wrote: > Hello > > http://bugs.sun.com/view_bug.do?bug_id=8006808 > > This check only worked as intended on Solaris/SPARC. For non-SPARC > architecture, egrep throws "egrep: syntax error" and the mapfile check > is skipped. > > The solution is to provide a search pattern in the else that is > acceptable to egrep: > > http://cr.openjdk.java.net/~tbell/8006808/00/ > > Thanks in advance for any feedback. > > Tim > From fredrik.ohrstrom at oracle.com Fri Feb 1 10:26:54 2013 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Fri, 01 Feb 2013 10:26:54 +0000 Subject: hg: jdk8/build: 2 new changesets Message-ID: <20130201102654.A2DE347745@hg.openjdk.java.net> Changeset: 12782ec1da5f Author: ohrstrom Date: 2013-01-31 14:00 +0100 URL: http://hg.openjdk.java.net/jdk8/build/rev/12782ec1da5f 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! common/autoconf/spec.gmk.in ! common/makefiles/JavaCompilation.gmk ! common/makefiles/javadoc/Javadoc.gmk Changeset: 7e584be2ee58 Author: ohrstrom Date: 2013-02-01 11:22 +0100 URL: http://hg.openjdk.java.net/jdk8/build/rev/7e584be2ee58 Merge From fredrik.ohrstrom at oracle.com Fri Feb 1 10:27:03 2013 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Fri, 01 Feb 2013 10:27:03 +0000 Subject: hg: jdk8/build/corba: 8006872: Stop creating four jars with identical content in the new build system. Message-ID: <20130201102705.96C0B47746@hg.openjdk.java.net> Changeset: ce106b6b7394 Author: ohrstrom Date: 2013-01-31 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/ce106b6b7394 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! makefiles/BuildCorba.gmk From fredrik.ohrstrom at oracle.com Fri Feb 1 10:27:47 2013 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Fri, 01 Feb 2013 10:27:47 +0000 Subject: hg: jdk8/build/jaxws: 8006872: Stop creating four jars with identical content in the new build system. Message-ID: <20130201102751.7516647748@hg.openjdk.java.net> Changeset: 54beebb17494 Author: ohrstrom Date: 2013-01-31 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/54beebb17494 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! makefiles/BuildJaxws.gmk From fredrik.ohrstrom at oracle.com Fri Feb 1 10:27:24 2013 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Fri, 01 Feb 2013 10:27:24 +0000 Subject: hg: jdk8/build/jaxp: 8006872: Stop creating four jars with identical content in the new build system. Message-ID: <20130201102732.2C04247747@hg.openjdk.java.net> Changeset: 8f6ca8755f46 Author: ohrstrom Date: 2013-01-31 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/8f6ca8755f46 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! makefiles/BuildJaxp.gmk From fredrik.ohrstrom at oracle.com Fri Feb 1 10:28:10 2013 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Fri, 01 Feb 2013 10:28:10 +0000 Subject: hg: jdk8/build/jdk: 8006872: Stop creating four jars with identical content in the new build system. Message-ID: <20130201102852.5371147749@hg.openjdk.java.net> Changeset: c5a7ac2a721f Author: ohrstrom Date: 2013-01-31 14:03 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c5a7ac2a721f 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! makefiles/CreateJars.gmk ! makefiles/GensrcSwing.gmk ! makefiles/Setup.gmk From fredrik.ohrstrom at oracle.com Fri Feb 1 10:29:08 2013 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Fri, 01 Feb 2013 10:29:08 +0000 Subject: hg: jdk8/build/langtools: 8006872: Stop creating four jars with identical content in the new build system. Message-ID: <20130201102915.211FC4774A@hg.openjdk.java.net> Changeset: 2d6789a725a4 Author: ohrstrom Date: 2013-01-31 14:01 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/2d6789a725a4 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! makefiles/BuildLangtools.gmk From erik.joelsson at oracle.com Fri Feb 1 12:07:56 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 01 Feb 2013 13:07:56 +0100 Subject: Review Request: 8007268: build-infra: configure reports Solaris needs gcc for deploy, but logs don't indicate it's used. Message-ID: <510BB01C.5030707@oracle.com> Removing the sanity check for ALT_GCC_COMPILER_PATH on Solaris since it's no longer used. http://cr.openjdk.java.net/~erikj/8007268/webrev.jdk.01/ /Erik From erik.joelsson at oracle.com Fri Feb 1 13:16:21 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 01 Feb 2013 14:16:21 +0100 Subject: Review Request: 8007275: build-infra: Create final-images target Message-ID: <510BC025.2010704@oracle.com> Open part of this review. Adding a target "final-images" which copies the images to use to the same location, regardless of platform. For OpenJDK, the only problem this solves is the overlay-images on Solaris 64bit, which have a different directory name to the normal images. This target is separate from the all and default targets and must be explicitly called, so it shouldn't bother anyone who doesn't want to use it. I put it in Jprt.gmk, part because it shares logic with the jprt specific bundles target but also because like jprt it's sort of Oracle specific. http://cr.openjdk.java.net/~erikj/8007275/webrev.root.01/ /Erik From erik.joelsson at oracle.com Fri Feb 1 13:29:02 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 01 Feb 2013 14:29:02 +0100 Subject: Review Request: 8007093: build-infra: Make should fail if spec is older than configure files Message-ID: <510BC31E.3040009@oracle.com> Adding a make rule for the spec file that depends on the autoconf source files and which will always fail if triggered. This guards from running make with an out of date configuration. http://cr.openjdk.java.net/~erikj/8007093/webrev.root.01/ /Erik From david.r.chase at oracle.com Fri Feb 1 13:49:12 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 1 Feb 2013 08:49:12 -0500 Subject: Questionable new-build failure In-Reply-To: <510B5BCC.4060000@oracle.com> References: <0CD3B4D3-44A6-4FCF-82C9-C4D47142400F@oracle.com> <5101BD14.8040903@oracle.com> <4D1C915D-7C99-42A0-AAE2-33C8BD62931B@oracle.com> <4E652F10-BE86-4DC8-8AA5-1414E6BDB043@oracle.com> <510B5BCC.4060000@oracle.com> Message-ID: There's another sort step that gets both sides. I thought I had seen success, and I just checked again, freshly configured and build with an 8 JAVA_HOME: /export/drchase/jdk8build(42)$JAVA_HOME/bin/java -version java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b73) Java HotSpot(TM) Server VM (build 25.0-b14, mixed mode) /export/drchase/jdk8build(43)uname -a SunOS intelsdv01 5.10 Generic_141445-09 i86pc i386 i86pc From jdk8/build, as of this morning, building on the same Solaris-10 box: grep sizes.64 with8.log /usr/bin/rm -f '...fastdebug/jdk/gensrc_x11wrappers/sizes.64' /usr/bin/sort /export/drchase/jdk8build/jdk/src/solaris/classes/sun/awt/X11/generator/sizes.64 > ...fastdebug/jdk/gensrc_x11wrappers/sizes.64 ...fastdebug/jdk/gensrc_x11wrappers/sizer.64.exe | /usr/bin/sort > ...fastdebug/jdk/gensrc_x11wrappers/sizes.64.verification.tmp /usr/bin/echo Verifying ...fastdebug/jdk/gensrc_x11wrappers/sizes.64.verification.tmp to ...fastdebug/jdk/gensrc_x11wrappers/sizes.64 Verifying ...fastdebug/jdk/gensrc_x11wrappers/sizes.64.verification.tmp to ...fastdebug/jdk/gensrc_x11wrappers/sizes.64 /pkg/gnu/bin/diff ...fastdebug/jdk/gensrc_x11wrappers/sizes.64.verification.tmp ...fastdebug/jdk/gensrc_x11wrappers/sizes.64 mv ...fastdebug/jdk/gensrc_x11wrappers/sizes.64.verification.tmp ...fastdebug/jdk/gensrc_x11wrappers/sizes.64.verification So one less worry. David On 2013-02-01, at 1:08 AM, David Holmes wrote: > I'm confused about this issue. My initial take was that this was caused by 8004151 because the files in the repo were not sorted, while the generated file was. > > Based on the changeset: > > http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/57d5d9544628 > > I see: > > + $(GENSRC_X11WRAPPERS_TMP)/sizer.$*.exe | $(SORT) > $@.tmp > > but this: > > +long 4 > +int 4 > +short 2 > +ptr 4 > +Bool 4 > +Atom 4 > +Window 4 > +XExtData.number 0 > ... > > does not appear sorted to me. > > David H. > ------- > > On 29/01/2013 6:41 AM, David Chase wrote: >> >> On 2013-01-25, at 4:55 PM, Kelly O'Hair wrote: >> >>> Please file JBS Issues. >> >> So this is a new bug that needs filing? I think it's sort of a duplicate, see below. >> >>> And keep in mind every "Solaris 10" system could be different. >> >> Solaris 10 10/09 s10x_u8wos_08a X86 >> Builds with jdk8, fails with jdk7. >> >> I am pretty sure that the cause of the bug is a dependence (in WrapperGenerator) on the order in which items are iterated out of a hash table. That appears to have changed in the transition from jdk7 to jdk8. That change was apparently necessary to make it (very much) harder to DOS a hashtable with collisions. I observed different output running WrapperGenerator with the exact same inputs under 7 and 8, cutting and pasting from a build and replacing only the target directory and the host VM. >> >> It seems to be fixed in jdk8-build as of six days ago (I checked), as a side-effect of fixing 8004151 >> >> David >> From chris.hegarty at oracle.com Fri Feb 1 14:40:38 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 01 Feb 2013 14:40:38 +0000 Subject: RFR: race with nested repos in hgforest.sh Message-ID: <510BD3E6.1090103@oracle.com> [ to build-dev and core-libs-dev, expect reviewer from either, but will integrate through jdk8/tl ] This issue is mainly of interest to Oracle engineers, but it effects the public hgforest script. When hgforest.sh is run with an addition argument to specify a closed server, there is a problem/race between the creation of the directories to hold nested repositories and the clone itself. These directories need to be created before the clone command is executed, otherwise it will fail, as below. The trivial fix is to back off these nested repos until their containing directory exists. Webrev: http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs Waiting 5 secs before spawning next background command. Waiting 5 secs before spawning next background command. Waiting 5 secs before spawning next background command. jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u /java/devtools/sparc/mercurial/latest/bin/hg clone http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed jdk/src/closed: abort: No such file or directory: jdk/src/closed jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u /java/devtools/sparc/mercurial/latest/bin/hg clone http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed jdk/make/closed: abort: No such file or directory: jdk/make/closed Waiting 5 secs before spawning next background command. .... -Chris. From tim.bell at oracle.com Fri Feb 1 14:41:35 2013 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 01 Feb 2013 06:41:35 -0800 Subject: Review Request: 8007268: build-infra: configure reports Solaris needs gcc for deploy, but logs don't indicate it's used. In-Reply-To: <510BB01C.5030707@oracle.com> References: <510BB01C.5030707@oracle.com> Message-ID: <510BD41F.2080801@oracle.com> Erik: > Removing the sanity check for ALT_GCC_COMPILER_PATH on Solaris since > it's no longer used. > > http://cr.openjdk.java.net/~erikj/8007268/webrev.jdk.01/ Looks good. Tim From tim.bell at oracle.com Fri Feb 1 15:03:59 2013 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 01 Feb 2013 07:03:59 -0800 Subject: Review Request: 8007275: build-infra: Create final-images target In-Reply-To: <510BC025.2010704@oracle.com> References: <510BC025.2010704@oracle.com> Message-ID: <510BD95F.4020800@oracle.com> Erik: > Open part of this review. > > Adding a target "final-images" which copies the images to use to the > same location, regardless of platform. For OpenJDK, the only problem > this solves is the overlay-images on Solaris 64bit, which have a > different directory name to the normal images. This target is separate > from the all and default targets and must be explicitly called, so it > shouldn't bother anyone who doesn't want to use it. > > I put it in Jprt.gmk, part because it shares logic with the jprt > specific bundles target but also because like jprt it's sort of Oracle > specific. > > http://cr.openjdk.java.net/~erikj/8007275/webrev.root.01/ Looks good. Tim From tim.bell at oracle.com Fri Feb 1 15:05:41 2013 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 01 Feb 2013 07:05:41 -0800 Subject: Review Request: 8007093: build-infra: Make should fail if spec is older than configure files In-Reply-To: <510BC31E.3040009@oracle.com> References: <510BC31E.3040009@oracle.com> Message-ID: <510BD9C5.1060806@oracle.com> Hi Erik: > Adding a make rule for the spec file that depends on the autoconf > source files and which will always fail if triggered. This guards from > running make with an out of date configuration. > > http://cr.openjdk.java.net/~erikj/8007093/webrev.root.01/ Looks good. Tim From tim.bell at oracle.com Fri Feb 1 17:18:19 2013 From: tim.bell at oracle.com (tim.bell at oracle.com) Date: Fri, 01 Feb 2013 17:18:19 +0000 Subject: hg: jdk8/build/jdk: 8006808: mapfile use check in jdk/make/common/shared/Defs-solaris.gmk is throwing 'egrep: syntax error' Message-ID: <20130201171832.55F964775E@hg.openjdk.java.net> Changeset: 35cf77f633c9 Author: tbell Date: 2013-02-01 09:16 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/35cf77f633c9 8006808: mapfile use check in jdk/make/common/shared/Defs-solaris.gmk is throwing 'egrep: syntax error' Summary: Use a valid egrep expression in the non-SPARC case Reviewed-by: dholmes ! make/common/shared/Defs-solaris.gmk From david.katleman at oracle.com Fri Feb 1 17:22:32 2013 From: david.katleman at oracle.com (David Katleman) Date: Fri, 01 Feb 2013 09:22:32 -0800 Subject: Review Request: 8007268: build-infra: configure reports Solaris needs gcc for deploy, but logs don't indicate it's used. In-Reply-To: <510BB01C.5030707@oracle.com> References: <510BB01C.5030707@oracle.com> Message-ID: <510BF9D8.6090005@oracle.com> On 2/1/2013 4:07 AM, Erik Joelsson wrote: > Removing the sanity check for ALT_GCC_COMPILER_PATH on Solaris since > it's no longer used. > > http://cr.openjdk.java.net/~erikj/8007268/webrev.jdk.01/ Looks correct. Excellent, good to get rid of this crufty old dependency that was never used. Thanks Dave From tim.bell at oracle.com Fri Feb 1 17:22:25 2013 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 01 Feb 2013 09:22:25 -0800 Subject: RFR: 8006808 mapfile use check in jdk/make/common/shared/Defs-solaris.gmk is throwing 'egrep: syntax error' In-Reply-To: <510B66D9.1020903@oracle.com> References: <510B5463.2050703@oracle.com> <510B66D9.1020903@oracle.com> Message-ID: <510BF9D1.6080309@oracle.com> On 01/31/13 22:55, David Holmes wrote: > Looks good to me Tim! Thanks, David. I pushed the change. The build logs are cluttered with spurious warnings, IMO. This change gets rid of a few of them. Tim From kelly.ohair at oracle.com Fri Feb 1 19:51:49 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 1 Feb 2013 11:51:49 -0800 Subject: Review request: 8006933: Need to use nawk on Solaris to avoid awk limitations In-Reply-To: <510AE812.90305@oracle.com> References: <51026031.7020200@oracle.com> <51065614.1090008@oracle.com> <51069AA2.3080007@oracle.com> <51095AEE.5020804@oracle.com> <510A2E8C.9040202@oracle.com> <510AE812.90305@oracle.com> Message-ID: <3F9A82DB-DF67-4C17-BC67-CD3D5662FD49@oracle.com> Tim, change looks good to me. Let's get this in. Thanks. -kto On Jan 31, 2013, at 1:54 PM, Tim Bell wrote: > On 01/31/13 00:42, David Holmes wrote: >> You mean even though the corba Defs-utils.gmk defines NAWK as awk this isn't a problem because it doesn't actually get used? > > Correct. It is set in corba/make/common/shared/Defs-utils.gmk but never used. This is probably an artifact of copying Defs-utils.gmk from the jdk repo. > > The only other place in corba using awk is in make/common/shared/Platform.gmk, and that section is BSD specific. > > Tim > From oehrstroem at gmail.com Fri Feb 1 10:39:45 2013 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Fri, 1 Feb 2013 11:39:45 +0100 Subject: One of THOSE changes has just been pushed.... Message-ID: I.e. 8006872: Stop creating four jars with identical content in the new build system. This changes makefiles in all repoes (but hotspot) and the spec.gmk file. I.e. you have rerun "sh get_source.sh" for the entire build forest and you have to rerun configure. Fortunately, these kind of changes are rare. //Fredrik From oehrstroem at gmail.com Fri Feb 1 12:58:56 2013 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Fri, 1 Feb 2013 13:58:56 +0100 Subject: This simple patch doubles the compile-speed of the hotspot repo on Windows Message-ID: ie. use /MP on the cl.exe command line. On the build machine (Windows Server 2007, Visual Studio 2010, 32 HT cores, 64GB ram) configuring with: sh configure --enable-sjavac --with-freetype=/cygdrive/d/tools/freetype-amd64 --with-boot-jdk=/cygdrive/d/java/jdk-7-fcs-bin-b147/ (You need to patch src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java line 256, change equals("windows)" to startswith("windows), this fix is going into tl soon.) Without MP ----- Build times ------- Start 2013-02-01 12:23:50 End 2013-02-01 12:35:20 00:00:32 corba 00:04:43 hotspot 00:00:15 jaxp 00:00:24 jaxws 00:04:49 jdk 00:00:46 langtools 00:11:30 TOTAL ------------------------- With MP ----- Build times ------- Start 2013-02-01 12:54:54 End 2013-02-01 13:03:56 00:00:31 corba 00:02:20 hotspot 00:00:14 jaxp 00:00:22 jaxws 00:04:44 jdk 00:00:46 langtools 00:09:02 TOTAL ------------------------- For such a simple patch it is a nice speedup. Please test and see if it improves the speed on your multi core machines. //Fredrik Oh, and for reference this is the speed without sjavac but with /MP. ----- Build times ------- Start 2013-02-01 13:39:38 End 2013-02-01 13:51:46 00:00:35 corba 00:02:24 hotspot 00:00:28 jaxp 00:00:36 jaxws 00:07:11 jdk 00:00:48 langtools 00:12:08 TOTAL ------------------------- $ hg diff diff -r 67498c863813 make/windows/makefiles/compile.make --- a/make/windows/makefiles/compile.make Thu Jan 17 12:16:06 2013 +0100 +++ b/make/windows/makefiles/compile.make Fri Feb 01 13:05:08 2013 +0100 @@ -44,6 +44,7 @@ # /GS Inserts security stack checks in some functions (VS2005 default) # /Oi Use intrinsics (in /O2) # /Od Disable all optimizations +# /MP Use multiple cores for compilation # # NOTE: Normally following any of the above with a '-' will turn off that flag # @@ -52,7 +53,7 @@ # improving the quality of crash log stack traces involving jvm.dll. # These are always used in all compiles -CXX_FLAGS=/nologo /W3 /WX +CXX_FLAGS=/nologo /W3 /WX /MP # Let's add debug information when Full Debug Symbols is enabled !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" diff -r 67498c863813 make/windows/makefiles/sa.make --- a/make/windows/makefiles/sa.make Thu Jan 17 12:16:06 2013 +0100 +++ b/make/windows/makefiles/sa.make Fri Feb 01 13:05:08 2013 +0100 @@ -108,6 +108,8 @@ SA_LFLAGS = $(SA_LFLAGS) -map -debug !endif +SA_CFLAGS = $(SA_CFLAGS) -MP + # Note that we do not keep sawindbj.obj around as it would then # get included in the dumpbin command in build_vm_def.sh From david.holmes at oracle.com Fri Feb 1 22:37:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 02 Feb 2013 08:37:28 +1000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510BD3E6.1090103@oracle.com> References: <510BD3E6.1090103@oracle.com> Message-ID: <510C43A8.7040805@oracle.com> Hi Chris, On 2/02/2013 12:40 AM, Chris Hegarty wrote: > [ to build-dev and core-libs-dev, expect reviewer from either, but will > integrate through jdk8/tl ] > > This issue is mainly of interest to Oracle engineers, but it effects the > public hgforest script. > > When hgforest.sh is run with an addition argument to specify a closed > server, there is a problem/race between the creation of the directories > to hold nested repositories and the clone itself. These directories need > to be created before the clone command is executed, otherwise it will > fail, as below. I think I reported this myself just last week - probably internally to build or build-infra. The weird thing is that based on the list of repos it shouldn't be grabbing the closed one yet. > The trivial fix is to back off these nested repos until their containing > directory exists. That seems to assume/require that the nested repo will always be later in the list. They happen to be but .... Workaround is to run get_source.sh twice first without the "extra base" then with it. David ----- > > Webrev: > http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ > > sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log > # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed > jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed > hotspot/test/closed deploy install sponsors pubs > > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > /java/devtools/sparc/mercurial/latest/bin/hg clone > http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed > jdk/src/closed: abort: No such file or directory: jdk/src/closed > jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > /java/devtools/sparc/mercurial/latest/bin/hg clone > http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed > jdk/make/closed: abort: No such file or directory: jdk/make/closed > Waiting 5 secs before spawning next background command. > .... > > > -Chris. From chris.hegarty at oracle.com Fri Feb 1 23:06:32 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 1 Feb 2013 23:06:32 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510C43A8.7040805@oracle.com> References: <510BD3E6.1090103@oracle.com> <510C43A8.7040805@oracle.com> Message-ID: On 1 Feb 2013, at 22:37, David Holmes wrote: > Hi Chris, > > On 2/02/2013 12:40 AM, Chris Hegarty wrote: >> [ to build-dev and core-libs-dev, expect reviewer from either, but will >> integrate through jdk8/tl ] >> >> This issue is mainly of interest to Oracle engineers, but it effects the >> public hgforest script. >> >> When hgforest.sh is run with an addition argument to specify a closed >> server, there is a problem/race between the creation of the directories >> to hold nested repositories and the clone itself. These directories need >> to be created before the clone command is executed, otherwise it will >> fail, as below. > > I think I reported this myself just last week - probably internally to build or build-infra. Ah, I missed that. > The weird thing is that based on the list of repos it shouldn't be grabbing the closed one yet. In my remote/slow environment I end up with all clones running concurrently. > >> The trivial fix is to back off these nested repos until their containing >> directory exists. > > That seems to assume/require that the nested repo will always be later in the list. They happen to be but .... No so. It will just wait for the process to clone the outer repo to start. > > Workaround is to run get_source.sh twice first without the "extra base" then with it. Good suggestion. -Chris > > David > ----- > >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >> >> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >> hotspot/test/closed deploy install sponsors pubs >> >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >> jdk/src/closed: abort: No such file or directory: jdk/src/closed >> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >> jdk/make/closed: abort: No such file or directory: jdk/make/closed >> Waiting 5 secs before spawning next background command. >> .... >> >> >> -Chris. From david.holmes at oracle.com Sat Feb 2 00:37:45 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 02 Feb 2013 10:37:45 +1000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: References: <510BD3E6.1090103@oracle.com> <510C43A8.7040805@oracle.com> Message-ID: <510C5FD9.902@oracle.com> On 2/02/2013 9:06 AM, Chris Hegarty wrote: > > On 1 Feb 2013, at 22:37, David Holmes wrote: > >> Hi Chris, >> >> On 2/02/2013 12:40 AM, Chris Hegarty wrote: >>> [ to build-dev and core-libs-dev, expect reviewer from either, but will >>> integrate through jdk8/tl ] >>> >>> This issue is mainly of interest to Oracle engineers, but it effects the >>> public hgforest script. >>> >>> When hgforest.sh is run with an addition argument to specify a closed >>> server, there is a problem/race between the creation of the directories >>> to hold nested repositories and the clone itself. These directories need >>> to be created before the clone command is executed, otherwise it will >>> fail, as below. >> >> I think I reported this myself just last week - probably internally to build or build-infra. > > Ah, I missed that. > >> The weird thing is that based on the list of repos it shouldn't be grabbing the closed one yet. > > In my remote/slow environment I end up with all clones running concurrently. I can see that happening if the sleeps are too short. But what I noticed from the logging was that the closed repos were being processed before the open ones - which shouldn't happen. >> >>> The trivial fix is to back off these nested repos until their containing >>> directory exists. >> >> That seems to assume/require that the nested repo will always be later in the list. They happen to be but .... > > No so. It will just wait for the process to clone the outer repo to start. Ok. Some clone will make progress and so we should ultimately get to start the outer repo. Thanks, David >> >> Workaround is to run get_source.sh twice first without the "extra base" then with it. > > Good suggestion. > > -Chris > >> >> David >> ----- >> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>> >>> sh ./get_source.sh http://xxx.yyy.oracle.com |& tee clone.log >>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >>> hotspot/test/closed deploy install sponsors pubs >>> >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>> Waiting 5 secs before spawning next background command. >>> .... >>> >>> >>> -Chris. From kelly.ohair at oracle.com Sat Feb 2 00:42:15 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 1 Feb 2013 16:42:15 -0800 Subject: This simple patch doubles the compile-speed of the hotspot repo on Windows In-Reply-To: References: Message-ID: <76DC1CA3-E0C7-4A2D-9E3D-4523C6A3D536@oracle.com> Great stuff. Have you filed an issue on this? Or shall I? -kto On Feb 1, 2013, at 4:58 AM, Fredrik ?hrstr?m wrote: > ie. use /MP on the cl.exe command line. > > On the build machine (Windows Server 2007, Visual Studio 2010, 32 HT > cores, 64GB ram) configuring with: > > sh configure --enable-sjavac > --with-freetype=/cygdrive/d/tools/freetype-amd64 > --with-boot-jdk=/cygdrive/d/java/jdk-7-fcs-bin-b147/ > > (You need to patch > src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java > line 256, change equals("windows)" to startswith("windows), this fix > is going into tl soon.) > > Without MP > ----- Build times ------- > Start 2013-02-01 12:23:50 > End 2013-02-01 12:35:20 > 00:00:32 corba > 00:04:43 hotspot > 00:00:15 jaxp > 00:00:24 jaxws > 00:04:49 jdk > 00:00:46 langtools > 00:11:30 TOTAL > ------------------------- > > With MP > ----- Build times ------- > Start 2013-02-01 12:54:54 > End 2013-02-01 13:03:56 > 00:00:31 corba > 00:02:20 hotspot > 00:00:14 jaxp > 00:00:22 jaxws > 00:04:44 jdk > 00:00:46 langtools > 00:09:02 TOTAL > ------------------------- > > For such a simple patch it is a nice speedup. Please test and see if > it improves the speed on your multi core machines. > > //Fredrik > > Oh, and for reference this is the speed without sjavac but with /MP. > > ----- Build times ------- > Start 2013-02-01 13:39:38 > End 2013-02-01 13:51:46 > 00:00:35 corba > 00:02:24 hotspot > 00:00:28 jaxp > 00:00:36 jaxws > 00:07:11 jdk > 00:00:48 langtools > 00:12:08 TOTAL > ------------------------- > > $ hg diff > diff -r 67498c863813 make/windows/makefiles/compile.make > --- a/make/windows/makefiles/compile.make Thu Jan 17 12:16:06 2013 +0100 > +++ b/make/windows/makefiles/compile.make Fri Feb 01 13:05:08 2013 +0100 > @@ -44,6 +44,7 @@ > # /GS Inserts security stack checks in some functions (VS2005 default) > # /Oi Use intrinsics (in /O2) > # /Od Disable all optimizations > +# /MP Use multiple cores for compilation > # > # NOTE: Normally following any of the above with a '-' will turn off that flag > # > @@ -52,7 +53,7 @@ > # improving the quality of crash log stack traces involving jvm.dll. > > # These are always used in all compiles > -CXX_FLAGS=/nologo /W3 /WX > +CXX_FLAGS=/nologo /W3 /WX /MP > > # Let's add debug information when Full Debug Symbols is enabled > !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" > diff -r 67498c863813 make/windows/makefiles/sa.make > --- a/make/windows/makefiles/sa.make Thu Jan 17 12:16:06 2013 +0100 > +++ b/make/windows/makefiles/sa.make Fri Feb 01 13:05:08 2013 +0100 > @@ -108,6 +108,8 @@ > SA_LFLAGS = $(SA_LFLAGS) -map -debug > !endif > > +SA_CFLAGS = $(SA_CFLAGS) -MP > + > # Note that we do not keep sawindbj.obj around as it would then > # get included in the dumpbin command in build_vm_def.sh From chris.hegarty at oracle.com Sat Feb 2 07:58:42 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 02 Feb 2013 07:58:42 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510C5FD9.902@oracle.com> References: <510BD3E6.1090103@oracle.com> <510C43A8.7040805@oracle.com> <510C5FD9.902@oracle.com> Message-ID: <510CC732.1070607@oracle.com> On 02/02/2013 12:37 AM, David Holmes wrote: > ... > > I can see that happening if the sleeps are too short. But what I noticed > from the logging was that the closed repos were being processed before > the open ones - which shouldn't happen. I believe the output is misleading. I think the output from the subprocesses, doing the clones, is being buffered and not quickly echoed by the parent process. This then gives the perception that they are executing first, when they are not. -Chris. From rnielsen at vocera.com Mon Feb 4 07:32:57 2013 From: rnielsen at vocera.com (Randy Nielsen) Date: Sun, 3 Feb 2013 23:32:57 -0800 Subject: problem building OpenJDK on Windows 7 in langtools Message-ID: <1AC3281AD57A34468B9879C754022CAF05F13E7DE2@exchange.vocera.local> I'm trying to build 64 bit java 7 on 64 bit Windows 7 with Cygwin, using instructions from http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html I built environment variables in Windows then simply typed "make". I get pass the sanity make sanity but choke fairly early in the langtools make. Full console output is at the end of the post. Here are the failure lines: -def-pcompile: [javac] Compiling 2 source files to C:\OpenJDK\jdk7-source\openjdk\build\windows-amd64\langtools\build\toolclasses BUILD FAILED C:\OpenJDK\jdk7-source\openjdk\langtools\make\build.xml:860: Error running \cygdrive\c\OpenJDK\jdk-6u37\bin\javac compiler Total time: 0 seconds make[2]: *** [build] Error 1 make[2]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk/langtools/make' make[1]: *** [langtools-build] Error 2 make[1]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk' make: *** [build_product_image] Error 2 I'm puzzled because the failure message appears to show that the build is trying to run javac with "\" separators instead of "/": \cygdrive\c\OpenJDK\jdk-6u37\bin\javac Invoking /cygdrive/c/OpenJDK/jdk-6u37/bin/javac works, producing the usual usage lines. On the surface the problem is \ vs. / but how can that be since ALT_BOOTDIR=/cygdrive/c/OpenJDK/jdk-6u37? So I could dig deeper I assumed that the problem was something else but can find no log file showing the parameters that javac was called with. Can anyone help? Thanks, Randy HERE IS THE FULL CYGWIN CONSOLE OUTPUT: Administrator at WIN-R7HSHTAIIHC ~ $ cd /cygdrive/c/OpenJDK/jdk7-source/openjdk Administrator at WIN-R7HSHTAIIHC /cygdrive/c/OpenJDK/jdk7-source/openjdk $ make cygwin warning: MS-DOS style path detected: C:/PROGRA~2/MI4ADD~1 Preferred POSIX equivalent is: /cygdrive/c/PROGRA~2/MI4ADD~1 CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames ( cd ./jdk/make && \ make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk JDK_MAKE_SHARED_DIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-administrator_2013_02_03_23_27-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="/cygdrive/c/OpenJDK/apache-ant-1.8.4" ALT_OUTPUTDIR=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 ALT_LANGTOOLS_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/dist ALT_CORBA_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/corba/dist ALT_JAXP_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxp/dist ALT_JAXWS_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxws/dist ALT_HOTSPOT_IMPORT_PATH=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import BUILD_HOTSPOT=true ; ) make[1]: Entering directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk/jdk/make' make[1]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk/jdk/make' Build Machine Information: build machine = WIN-R7HSHTAIIHC Build Directory Structure: CWD = /cygdrive/c/OpenJDK/jdk7-source/openjdk TOPDIR = . LANGTOOLS_TOPDIR = ./langtools JAXP_TOPDIR = ./jaxp JAXWS_TOPDIR = ./jaxws CORBA_TOPDIR = ./corba HOTSPOT_TOPDIR = ./hotspot JDK_TOPDIR = ./jdk Build Directives: BUILD_LANGTOOLS = true BUILD_JAXP = true BUILD_JAXWS = true BUILD_CORBA = true BUILD_HOTSPOT = true BUILD_JDK = true DEBUG_CLASSFILES = DEBUG_BINARIES = Hotspot Settings: HOTSPOT_BUILD_JOBS = HOTSPOT_OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/outputdir HOTSPOT_EXPORT_PATH = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import Bootstrap Settings: BOOTDIR = /cygdrive/c/OpenJDK/jdk-6u37 ALT_BOOTDIR = /cygdrive/c/OpenJDK/jdk-6u37 BOOT_VER = 1.6.0 [requires at least 1.6] OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 ALT_OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 ABS_OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 Build Tool Settings: SLASH_JAVA = J: ALT_SLASH_JAVA = VARIANT = OPT JDK_DEVTOOLS_DIR = J:/devtools ALT_JDK_DEVTOOLS_DIR = ANT_HOME = /cygdrive/c/OpenJDK/apache-ant-1.8.4 UNIXCOMMAND_PATH = /usr/bin/ ALT_UNIXCOMMAND_PATH = COMPILER_PATH = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/ ALT_COMPILER_PATH = DEVTOOLS_PATH = /usr/bin/ ALT_DEVTOOLS_PATH = MSVCRNN_DLL_PATH = C:/Windows/system32 ALT_MSVCRNN_DLL_PATH = INCLUDE = C:/msvs2012/VC/include;C:/MSSDKWIN7/Windows/v7.1/Include LIB = C:/msvs2012/VC/lib/amd64;C:/MSSDKWIN7/Windows/v7.1/Lib/x64 COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) COMPILER_VERSION = VS2010 CC_VER = 16.00.30319.01 [requires at least 16.00.30319.01] ZIP_VER = 3.0 [requires at least 2.2] UNZIP_VER = 6.00 [requires at least 5.12] LINK_VER = 10.00.30319.01 [requires at least 10.00.30319.01] CC = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/cl LINK = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/link DUMPBIN = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe ANT_VER = 1.8.4 [requires at least 1.7.1] TEMPDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp Build Directives: OPENJDK = true USE_HOTSPOT_INTERPRETER_MODE = PEDANTIC = DEV_ONLY = NO_DOCS = NO_IMAGES = TOOLS_ONLY = INSANE = COMPILE_APPROACH = normal FASTDEBUG = COMPILER_WARNINGS_FATAL = false COMPILER_WARNING_LEVEL = 3 SHOW_ALL_WARNINGS = false INCREMENTAL_BUILD = false CC_HIGHEST_OPT = CC_HIGHER_OPT = CC_LOWER_OPT = CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE BOOT_JAVA_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m BOOT_JAVAC_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/javac -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 -XDignore.symbol.file=true BOOT_JAR_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/jar BOOT_JARSIGNER_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/jarsigner Build Platform Settings: USER = Administrator PLATFORM = windows ARCH = amd64 LIBARCH = amd64 ARCH_FAMILY = amd64 ARCH_DATA_MODEL = 64 ARCHPROP = amd64 PROCESSOR_ARCHITECTURE = x86 PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 26 Stepping 5, GenuineIntel USING_CYGWIN = true CYGWIN_VER = 6.1 [requires at least 4.0] CYGPATH_CMD = cygpath -a -s -m OS_VERSION = 6.1 [requires at least 5.2] OS_VARIANT_NAME = OS_VARIANT_VERSION = 6.1 MB_OF_MEMORY = 1023 GNU Make Settings: MAKE = make MAKE_VER = 3.82 [requires at least 3.81] MAKECMDGOALS = sanity MAKEFLAGS = w SHELL = /bin/sh Target Build Versions: JDK_VERSION = 1.7.0 MILESTONE = internal RELEASE = 1.7.0-internal FULL_VERSION = 1.7.0-internal-administrator_2013_02_03_23_27-b00 BUILD_NUMBER = b00 External File/Binary Locations: USRJDKINSTANCES_PATH = C:/PROGRA~1/Java BUILD_JDK_IMPORT_PATH = J:/re/jdk/1.7.0/promoted/latest/binaries ALT_BUILD_JDK_IMPORT_PATH = JDK_IMPORT_PATH = J:/re/jdk/1.7.0/promoted/latest/binaries/windows-amd64 ALT_JDK_IMPORT_PATH = LANGTOOLS_DIST = ALT_LANGTOOLS_DIST = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/dist CORBA_DIST = ALT_CORBA_DIST = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/corba/dist JAXP_DIST = ALT_JAXP_DIST = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxp/dist JAXWS_DIST = ALT_JAXWS_DIST = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxws/dist HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR ALT_HOTSPOT_DOCS_IMPORT_PATH = HOTSPOT_IMPORT_PATH = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import ALT_HOTSPOT_IMPORT_PATH = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import HOTSPOT_SERVER_PATH = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import/jre/bin/server ALT_HOTSPOT_SERVER_PATH = HOTSPOT_LIB_PATH = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import/lib ALT_HOTSPOT_LIB_PATH = DXSDK_VER = 0x0900 DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 ALT_DXSDK_PATH = DXSDK_INCLUDE_PATH = C:/PROGRA~2/MI4ADD~1/Include ALT_DXSDK_INCLUDE_PATH = DXSDK_LIB_PATH = C:/PROGRA~2/MI4ADD~1/Lib/x64 ALT_DXSDK_LIB_PATH = WINDOWSSDKDIR = c:\MSSDKWIN7\Windows 7.1/ ALT_WINDOWSSDKDIR = RC = c:\MSSDKWIN7\Windows 7.1//Bin/x64/RC.Exe REBASE = c:\MSSDKWIN7\Windows 7.1//Bin/x64/ReBase.Exe CACERTS_FILE = ./../src/share/lib/security/cacerts ALT_CACERTS_FILE = OpenJDK-specific settings: FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include ALT_FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 ALT_FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 Previous JDK Settings: PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE ALT_PREVIOUS_RELEASE_PATH = PREVIOUS_JDK_VERSION = 1.6.0 ALT_PREVIOUS_JDK_VERSION = PREVIOUS_JDK_FILE = ALT_PREVIOUS_JDK_FILE = PREVIOUS_JRE_FILE = ALT_PREVIOUS_JRE_FILE = PREVIOUS_RELEASE_IMAGE = /cygdrive/c/OpenJDK/jdk-6u37 ALT_PREVIOUS_RELEASE_IMAGE = Sanity check passed. make \ SKIP_FASTDEBUG_BUILD=true \ SKIP_DEBUG_BUILD=true \ \ generic_build_repo_series make[1]: Entering directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk' /usr/bin/mkdir -p ./build/windows-amd64/j2sdk-image /usr/bin/mkdir -p C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools ######################################################################## ######################################################################## ##### Entering langtools for target(s) all ##### ######################################################################## (cd ./langtools/make && \ make JDK_TOPDIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk JDK_MAKE_SHARED_DIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-administrator_2013_02_03_23_27-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="/cygdrive/c/OpenJDK/apache-ant-1.8.4" ALT_OUTPUTDIR=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools ALT_BOOTDIR=/cygdrive/c/OpenJDK/jdk-6u37 all) make[2]: Entering directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk/langtools/make' JAVA_HOME=/cygdrive/c/OpenJDK/jdk-6u37 ANT_OPTS=-Djava.io.tmpdir='C:/OpenJDK/JDK7-S~1/openjdk/build/WINDOW~1/LANGTO~1/build/ant-tmp' /cygdrive/c/OpenJDK/apache-ant-1.8.4/bin/ant -Djdk.version=1.7.0 -Dfull.version='1.7.0-internal-administrator_2013_02_03_23_27-b00' -Dmilestone=internal -Dbuild.number=b00 -Djavac.target=7 -Djavac.source=7 -Dboot.java.home=/cygdrive/c/OpenJDK/jdk-6u37 -Dimport.jdk=C:/OpenJDK/JDK7-S~1/openjdk/jdk -Dbuild.dir=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/build -Ddist.dir=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/dist build Buildfile: C:\OpenJDK\jdk7-source\openjdk\langtools\make\build.xml -def-pcompile: [javac] Compiling 2 source files to C:\OpenJDK\jdk7-source\openjdk\build\windows-amd64\langtools\build\toolclasses BUILD FAILED C:\OpenJDK\jdk7-source\openjdk\langtools\make\build.xml:860: Error running \cygdrive\c\OpenJDK\jdk-6u37\bin\javac compiler Total time: 0 seconds make[2]: *** [build] Error 1 make[2]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk/langtools/make' make[1]: *** [langtools-build] Error 2 make[1]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk' make: *** [build_product_image] Error 2 Administrator at WIN-R7HSHTAIIHC /cygdrive/c/OpenJDK/jdk7-source/openjdk $ From oehrstroem at gmail.com Mon Feb 4 09:04:30 2013 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Mon, 4 Feb 2013 10:04:30 +0100 Subject: This simple patch doubles the compile-speed of the hotspot repo on Windows In-Reply-To: <76DC1CA3-E0C7-4A2D-9E3D-4523C6A3D536@oracle.com> References: <76DC1CA3-E0C7-4A2D-9E3D-4523C6A3D536@oracle.com> Message-ID: Issue filed, on its way in: http://cr.openjdk.java.net/~ohrstrom/webrev-8007446-add-MP/ //Fredrik 2013/2/2 Kelly O'Hair : > Great stuff. Have you filed an issue on this? Or shall I? > > > -kto > > On Feb 1, 2013, at 4:58 AM, Fredrik ?hrstr?m wrote: > >> ie. use /MP on the cl.exe command line. >> >> On the build machine (Windows Server 2007, Visual Studio 2010, 32 HT >> cores, 64GB ram) configuring with: >> >> sh configure --enable-sjavac >> --with-freetype=/cygdrive/d/tools/freetype-amd64 >> --with-boot-jdk=/cygdrive/d/java/jdk-7-fcs-bin-b147/ >> >> (You need to patch >> src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java >> line 256, change equals("windows)" to startswith("windows), this fix >> is going into tl soon.) >> >> Without MP >> ----- Build times ------- >> Start 2013-02-01 12:23:50 >> End 2013-02-01 12:35:20 >> 00:00:32 corba >> 00:04:43 hotspot >> 00:00:15 jaxp >> 00:00:24 jaxws >> 00:04:49 jdk >> 00:00:46 langtools >> 00:11:30 TOTAL >> ------------------------- >> >> With MP >> ----- Build times ------- >> Start 2013-02-01 12:54:54 >> End 2013-02-01 13:03:56 >> 00:00:31 corba >> 00:02:20 hotspot >> 00:00:14 jaxp >> 00:00:22 jaxws >> 00:04:44 jdk >> 00:00:46 langtools >> 00:09:02 TOTAL >> ------------------------- >> >> For such a simple patch it is a nice speedup. Please test and see if >> it improves the speed on your multi core machines. >> >> //Fredrik >> >> Oh, and for reference this is the speed without sjavac but with /MP. >> >> ----- Build times ------- >> Start 2013-02-01 13:39:38 >> End 2013-02-01 13:51:46 >> 00:00:35 corba >> 00:02:24 hotspot >> 00:00:28 jaxp >> 00:00:36 jaxws >> 00:07:11 jdk >> 00:00:48 langtools >> 00:12:08 TOTAL >> ------------------------- >> >> $ hg diff >> diff -r 67498c863813 make/windows/makefiles/compile.make >> --- a/make/windows/makefiles/compile.make Thu Jan 17 12:16:06 2013 +0100 >> +++ b/make/windows/makefiles/compile.make Fri Feb 01 13:05:08 2013 +0100 >> @@ -44,6 +44,7 @@ >> # /GS Inserts security stack checks in some functions (VS2005 default) >> # /Oi Use intrinsics (in /O2) >> # /Od Disable all optimizations >> +# /MP Use multiple cores for compilation >> # >> # NOTE: Normally following any of the above with a '-' will turn off that flag >> # >> @@ -52,7 +53,7 @@ >> # improving the quality of crash log stack traces involving jvm.dll. >> >> # These are always used in all compiles >> -CXX_FLAGS=/nologo /W3 /WX >> +CXX_FLAGS=/nologo /W3 /WX /MP >> >> # Let's add debug information when Full Debug Symbols is enabled >> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >> diff -r 67498c863813 make/windows/makefiles/sa.make >> --- a/make/windows/makefiles/sa.make Thu Jan 17 12:16:06 2013 +0100 >> +++ b/make/windows/makefiles/sa.make Fri Feb 01 13:05:08 2013 +0100 >> @@ -108,6 +108,8 @@ >> SA_LFLAGS = $(SA_LFLAGS) -map -debug >> !endif >> >> +SA_CFLAGS = $(SA_CFLAGS) -MP >> + >> # Note that we do not keep sawindbj.obj around as it would then >> # get included in the dumpbin command in build_vm_def.sh > From chris.hegarty at oracle.com Mon Feb 4 09:48:57 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 04 Feb 2013 09:48:57 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510BD3E6.1090103@oracle.com> References: <510BD3E6.1090103@oracle.com> Message-ID: <510F8409.6080202@oracle.com> There has been some discussion on this with David, but no other takers. Fredrik, am I right that you added the support for parallel clone/update? I believe the changes I have are correct, but maybe you had other ideas about how to solve this issue? -Chris. On 01/02/2013 14:40, Chris Hegarty wrote: > [ to build-dev and core-libs-dev, expect reviewer from either, but will > integrate through jdk8/tl ] > > This issue is mainly of interest to Oracle engineers, but it effects the > public hgforest script. > > When hgforest.sh is run with an addition argument to specify a closed > server, there is a problem/race between the creation of the directories > to hold nested repositories and the clone itself. These directories need > to be created before the clone command is executed, otherwise it will > fail, as below. > > The trivial fix is to back off these nested repos until their containing > directory exists. > > Webrev: > http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ > > sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log > # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed > jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed > hotspot/test/closed deploy install sponsors pubs > > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > /java/devtools/sparc/mercurial/latest/bin/hg clone > http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed > jdk/src/closed: abort: No such file or directory: jdk/src/closed > jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > /java/devtools/sparc/mercurial/latest/bin/hg clone > http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed > jdk/make/closed: abort: No such file or directory: jdk/make/closed > Waiting 5 secs before spawning next background command. > .... > > > -Chris. From martijnverburg at gmail.com Mon Feb 4 09:52:31 2013 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 4 Feb 2013 09:52:31 +0000 Subject: problem building OpenJDK on Windows 7 in langtools In-Reply-To: <1AC3281AD57A34468B9879C754022CAF05F13E7DE2@exchange.vocera.local> References: <1AC3281AD57A34468B9879C754022CAF05F13E7DE2@exchange.vocera.local> Message-ID: I'm on my phone so can't check this specific case but we do have slightly more up to date instructions on the adoptopenjdk.java.net wiki for windows builds, so perhaps you can try there. Cheers, Martijn PS: Yes these instructions are coming back to OpenJDK working on that with Dalibor soon On Monday, 4 February 2013, Randy Nielsen wrote: > I'm trying to build 64 bit java 7 on 64 bit Windows 7 with Cygwin, using > instructions from > http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html > > I built environment variables in Windows then simply typed "make". I get > pass the sanity make sanity but choke fairly early in the langtools make. > Full console output is at the end of the post. Here are the failure lines: > > > -def-pcompile: > [javac] Compiling 2 source files to > C:\OpenJDK\jdk7-source\openjdk\build\windows-amd64\langtools\build\toolclasses > > BUILD FAILED > C:\OpenJDK\jdk7-source\openjdk\langtools\make\build.xml:860: Error running > \cygdrive\c\OpenJDK\jdk-6u37\bin\javac compiler > > Total time: 0 seconds > make[2]: *** [build] Error 1 > make[2]: Leaving directory > `/cygdrive/c/OpenJDK/jdk7-source/openjdk/langtools/make' > make[1]: *** [langtools-build] Error 2 > make[1]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk' > make: *** [build_product_image] Error 2 > > > I'm puzzled because the failure message appears to show that the build is > trying to run javac with "\" separators instead of "/": > \cygdrive\c\OpenJDK\jdk-6u37\bin\javac > > Invoking /cygdrive/c/OpenJDK/jdk-6u37/bin/javac works, producing the usual > usage lines. > > On the surface the problem is \ vs. / but how can that be since > ALT_BOOTDIR=/cygdrive/c/OpenJDK/jdk-6u37? So I could dig deeper I assumed > that > the problem was something else but can find no log file showing the > parameters that javac was called with. > > Can anyone help? > > Thanks, > > Randy > > HERE IS THE FULL CYGWIN CONSOLE OUTPUT: > > Administrator at WIN-R7HSHTAIIHC ~ > $ cd /cygdrive/c/OpenJDK/jdk7-source/openjdk > > Administrator at WIN-R7HSHTAIIHC /cygdrive/c/OpenJDK/jdk7-source/openjdk > $ make > cygwin warning: > MS-DOS style path detected: C:/PROGRA~2/MI4ADD~1 > Preferred POSIX equivalent is: /cygdrive/c/PROGRA~2/MI4ADD~1 > CYGWIN environment variable option "nodosfilewarning" turns off this > warning. > Consult the user's guide for more details about POSIX paths: > http://cygwin.com/cygwin-ug-net/using.html#using-pathnames > ( cd ./jdk/make && \ > make sanity HOTSPOT_IMPORT_CHECK=false > JDK_TOPDIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk > JDK_MAKE_SHARED_DIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk/make/common/shared > EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 > MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 > FULL_VERSION=1.7.0-internal-administrator_2013_02_03_23_27-b00 > PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 > JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 > PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 > ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 > ANT_HOME="/cygdrive/c/OpenJDK/apache-ant-1.8.4" > ALT_OUTPUTDIR=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 > ALT_LANGTOOLS_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/dist > ALT_CORBA_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/corba/dist > ALT_JAXP_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxp/dist > ALT_JAXWS_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxws/dist > ALT_HOTSPOT_IMPORT_PATH=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import > BUILD_HOTSPOT=true ; ) > make[1]: Entering directory > `/cygdrive/c/OpenJDK/jdk7-source/openjdk/jdk/make' > make[1]: Leaving directory > `/cygdrive/c/OpenJDK/jdk7-source/openjdk/jdk/make' > > Build Machine Information: > build machine = WIN-R7HSHTAIIHC > > Build Directory Structure: > CWD = /cygdrive/c/OpenJDK/jdk7-source/openjdk > TOPDIR = . > LANGTOOLS_TOPDIR = ./langtools > JAXP_TOPDIR = ./jaxp > JAXWS_TOPDIR = ./jaxws > CORBA_TOPDIR = ./corba > HOTSPOT_TOPDIR = ./hotspot > JDK_TOPDIR = ./jdk > > Build Directives: > BUILD_LANGTOOLS = true > BUILD_JAXP = true > BUILD_JAXWS = true > BUILD_CORBA = true > BUILD_HOTSPOT = true > BUILD_JDK = true > DEBUG_CLASSFILES = > DEBUG_BINARIES = > > Hotspot Settings: > HOTSPOT_BUILD_JOBS = > HOTSPOT_OUTPUTDIR = > C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/outputdir > HOTSPOT_EXPORT_PATH = > C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import > > > > > Bootstrap Settings: > BOOTDIR = /cygdrive/c/OpenJDK/jdk-6u37 > ALT_BOOTDIR = /cygdrive/c/OpenJDK/jdk-6u37 > BOOT_VER = 1.6.0 [requires at least 1.6] > OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 > ALT_OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 > ABS_OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 > > Build Tool Settings: > SLASH_JAVA = J: > ALT_SLASH_JAVA = > VARIANT = OPT > JDK_DEVTOOLS_DIR = J:/devtools > ALT_JDK_DEVTOOLS_DIR = > ANT_HOME = /cygdrive/c/OpenJDK/apache-ant-1.8.4 > UNIXCOMMAND_PATH = /usr/bin/ > ALT_UNIXCOMMAND_PATH = > COMPILER_PATH = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/ > ALT_COMPILER_PATH = > DEVTOOLS_PATH = /usr/bin/ > ALT_DEVTOOLS_PATH = > MSVCRNN_DLL_PATH = C:/Windows/system32 > ALT_MSVCRNN_DLL_PATH = > INCLUDE = C:/msvs2012/VC/include;C:/MSSDKWIN7/Windows/v7.1/Include > LIB = C:/msvs2012/VC/lib/amd64;C:/MSSDKWIN7/Windows/v7.1/Lib/x64 > COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) > COMPILER_VERSION = VS2010 > CC_VER = 16.00.30319.01 [requires at least 16.00.30319.01] > ZIP_VER = 3.0 [requires at least 2.2] > UNZIP_VER = 6.00 [requires at least 5.12] > LINK_VER = 10.00.30319.01 [requires at least 10.00.30319.01] > CC = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/cl > LINK = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/link > DUMPBIN = > C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe > ANT_VER = 1.8.4 [requires at least 1.7.1] > TEMPDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp > > Build Directives: > OPENJDK = true > USE_HOTSPOT_INTERPRETER_MODE = > PEDANTIC = > DEV_ONLY = > NO_DOCS = > NO_IMAGES = > TOOLS_ONLY = > INSANE = > COMPILE_APPROACH = normal > FASTDEBUG = > COMPILER_WARNINGS_FATAL = false > COMPILER_WARNING_LEVEL = 3 > SHOW_ALL_WARNINGS = false > INCREMENTAL_BUILD = false > CC_HIGHEST_OPT = > CC_HIGHER_OPT = > CC_LOWER_OPT = > CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D > _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- > -FdC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.pdb > -FmC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.map > -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE > CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D > _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- > -FdC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.pdb > -FmC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.map > -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE > BOOT_JAVA_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/java > -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput > -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m > BOOT_JAVAC_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/javac > -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions > -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m > -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target > 6 -XDignore.symbol.file=true > BOOT_JAR_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/jar > BOOT_JARSIGNER_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/jarsigner > > Build Platform Settings: > USER = Administrator > PLATFORM = windows > ARCH = amd64 > LIBARCH = amd64 > ARCH_FAMILY = amd64 > ARCH_DATA_MODEL = 64 > ARCHPROP = amd64 > PROCESSOR_ARCHITECTURE = x86 > PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 26 Stepping 5, GenuineIntel > USING_CYGWIN = true > CYGWIN_VER = 6.1 [requires at least 4.0] > CYGPATH_CMD = cygpath -a -s -m > OS_VERSION = 6.1 [requires at least 5.2] > OS_VARIANT_NAME = > OS_VARIANT_VERSION = 6.1 > MB_OF_MEMORY = 1023 > > GNU Make Settings: > MAKE = make > MAKE_VER = 3.82 [requires at least 3.81] > MAKECMDGOALS = sanity > MAKEFLAGS = w > SHELL = /bin/sh > > Target Build Versions: > JDK_VERSION = 1.7.0 > MILESTONE = internal > RELEASE = 1.7.0-internal > FULL_VERSION = 1.7.0-internal-administrator_2013_02_03_23_27-b00 > BUILD_NUMBER = b00 > > External File/Binary Locations: > USRJDKINSTANCES_PATH = C:/PROGRA~1/Java > BUILD_JDK_IMPORT_PATH = J:/re/jdk/1.7.0/promoted/latest/binaries > ALT_BUILD_JDK_IMPORT_PATH = > JDK_IMPORT_PATH = J:/re/jdk/1.7.0/promoted/latest/binaries/windows-amd64 > ALT_JDK_IMPORT_PATH = > LANGTOOLS_DIST = > ALT_LANGTOOLS_DIST = > C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/dist > CORBA_DIST = > ALT_CORBA_DIST = > C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/corba/dist > JAXP_DIST = > ALT_JAXP_DIST = > C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxp/dist > JAXWS_DIST = > ALT_JAXWS_DIST = > C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxws/dist > HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR > ALT_HOTSPOT_DOCS_IMPORT_PATH = > HOTSPOT_IMPORT_PATH = > C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import > ALT_HOTSPOT_IMPORT_PATH = > C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import > HOTSPOT_SERVER_PATH = > C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import/jre/bin/server > ALT_HOTSPOT_SERVER_PATH = > HOTSPOT_LIB_PATH = > C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import/lib > ALT_HOTSPOT_LIB_PATH = > DXSDK_VER = 0x0900 > DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 > ALT_DXSDK_PATH = > DXSDK_INCLUDE_PATH = C:/PROGRA~2/MI4ADD~1/Include > ALT_DXSDK_INCLUDE_PATH = > DXSDK_LIB_PATH = C:/PROGRA~2/MI4ADD~1/Lib/x64 > ALT_DXSDK_LIB_PATH = > WINDOWSSDKDIR = c:\MSSDKWIN7\Windows > 7.1/ > ALT_WINDOWSSDKDIR = > RC = c:\MSSDKWIN7\Windows > 7.1//Bin/x64/RC.Exe > REBASE = c:\MSSDKWIN7\Windows > 7.1//Bin/x64/ReBase.Exe > CACERTS_FILE = ./../src/share/lib/security/cacerts > ALT_CACERTS_FILE = > > OpenJDK-specific settings: > FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include > ALT_FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include > FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 > ALT_FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 > > Previous JDK Settings: > PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE > ALT_PREVIOUS_RELEASE_PATH = > PREVIOUS_JDK_VERSION = 1.6.0 > ALT_PREVIOUS_JDK_VERSION = > PREVIOUS_JDK_FILE = > ALT_PREVIOUS_JDK_FILE = > PREVIOUS_JRE_FILE = > ALT_PREVIOUS_JRE_FILE = > PREVIOUS_RELEASE_IMAGE = /cygdrive/c/OpenJDK/jdk-6u37 > ALT_PREVIOUS_RELEASE_IMAGE = > > > Sanity check passed. > make \ > SKIP_FASTDEBUG_BUILD=true \ > SKIP_DEBUG_BUILD=true \ > \ > generic_build_repo_series > make[1]: Entering directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk' > /usr/bin/mkdir -p ./build/windows-amd64/j2sdk-image > /usr/bin/mkdir -p > C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools > > > ######################################################################## > ######################################################################## > ##### Entering langtools for target(s) all ##### > ######################################################################## > > (cd ./langtools/make && \ > make JDK_TOPDIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk > JDK_MAKE_SHARED_DIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk/make/common/shared > EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 > MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 > FULL_VERSION=1.7.0-internal-administrator_2013_02_03_23_27-b00 > PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 > JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 > PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 > ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 > ANT_HOME="/cygdrive/c/OpenJDK/apache-ant-1.8.4" > ALT_OUTPUTDIR=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools > ALT_BOOTDIR=/cygdrive/c/OpenJDK/jdk-6u37 all) > make[2]: Entering directory > `/cygdrive/c/OpenJDK/jdk7-source/openjdk/langtools/make' > JAVA_HOME=/cygdrive/c/OpenJDK/jdk-6u37 > ANT_OPTS=-Djava.io.tmpdir='C:/OpenJDK/JDK7-S~1/openjdk/build/WINDOW~1/LANGTO~1/build/ant-tmp' > /cygdrive/c/OpenJDK/apache-ant-1.8.4/bin/ant -Djdk.version=1.7.0 > -Dfull.version='1.7.0-internal-administrator_2013_02_03_23_27-b00' > -Dmilestone=internal -Dbuild.number=b00 -Djavac.target=7 -Djavac.source=7 > -Dboot.java.home=/cygdrive/c/OpenJDK/jdk-6u37 > -Dimport.jdk=C:/OpenJDK/JDK7-S~1/openjdk/jdk > -Dbuild.dir=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/build > -Ddist.dir=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/dist > build > Buildfile: C:\OpenJDK\jdk7-source\openjdk\langtools\make\build.xml > > -def-pcompile: > [javac] Compiling 2 source files to > C:\OpenJDK\jdk7-source\openjdk\build\windows-amd64\langtools\build\toolclasses > > BUILD FAILED > C:\OpenJDK\jdk7-source\openjdk\langtools\make\build.xml:860: Error running > \cygdrive\c\OpenJDK\jdk-6u37\bin\javac compiler > > Total time: 0 seconds > make[2]: *** [build] Error 1 > make[2]: Leaving directory > `/cygdrive/c/OpenJDK/jdk7-source/openjdk/langtools/make' > make[1]: *** [langtools-build] Error 2 > make[1]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk' > make: *** [build_product_image] Error 2 > > Administrator at WIN-R7HSHTAIIHC /cygdrive/c/OpenJDK/jdk7-source/openjdk > $ > > > > > > > > > > > From fredrik.ohrstrom at oracle.com Mon Feb 4 10:04:27 2013 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Mon, 04 Feb 2013 11:04:27 +0100 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510F8409.6080202@oracle.com> References: <510BD3E6.1090103@oracle.com> <510F8409.6080202@oracle.com> Message-ID: <510F87AB.3070705@oracle.com> 2013-02-04 10:48, Chris Hegarty skrev: > There has been some discussion on this with David, but no other takers. > > Fredrik, am I right that you added the support for parallel > clone/update? I believe the changes I have are correct, but maybe you > had other ideas about how to solve this issue? > > -Chris. I did not add the support for parallel clone/update. It was there already and causing problems. I added the functionality to interrupt the script using ctrl-c, which was impossible before, because of the parallel clone/update code. Your fix looks good and is simple enough. //Fredrik > > On 01/02/2013 14:40, Chris Hegarty wrote: >> [ to build-dev and core-libs-dev, expect reviewer from either, but will >> integrate through jdk8/tl ] >> >> This issue is mainly of interest to Oracle engineers, but it effects the >> public hgforest script. >> >> When hgforest.sh is run with an addition argument to specify a closed >> server, there is a problem/race between the creation of the directories >> to hold nested repositories and the clone itself. These directories need >> to be created before the clone command is executed, otherwise it will >> fail, as below. >> >> The trivial fix is to back off these nested repos until their containing >> directory exists. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >> >> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >> hotspot/test/closed deploy install sponsors pubs >> >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >> jdk/src/closed: abort: No such file or directory: jdk/src/closed >> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >> jdk/make/closed: abort: No such file or directory: jdk/make/closed >> Waiting 5 secs before spawning next background command. >> .... >> >> >> -Chris. From chris.hegarty at oracle.com Mon Feb 4 10:23:36 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 04 Feb 2013 10:23:36 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510F87AB.3070705@oracle.com> References: <510BD3E6.1090103@oracle.com> <510F8409.6080202@oracle.com> <510F87AB.3070705@oracle.com> Message-ID: <510F8C28.9030204@oracle.com> On 04/02/2013 10:04, Fredrik ?hrstr?m wrote: > 2013-02-04 10:48, Chris Hegarty skrev: >> There has been some discussion on this with David, but no other takers. >> >> Fredrik, am I right that you added the support for parallel >> clone/update? I believe the changes I have are correct, but maybe you >> had other ideas about how to solve this issue? >> >> -Chris. > > I did not add the support for parallel clone/update. It was there > already and causing problems. Ah sorry Fredrik, I remember the ctrl-c stuff now. I didn't mean to implicate you, just thought you would be familiar with this area. > I added the functionality to interrupt the script using ctrl-c, which > was impossible before, because > of the parallel clone/update code. > > Your fix looks good and is simple enough. Thanks, -Chris. > > //Fredrik > >> >> On 01/02/2013 14:40, Chris Hegarty wrote: >>> [ to build-dev and core-libs-dev, expect reviewer from either, but will >>> integrate through jdk8/tl ] >>> >>> This issue is mainly of interest to Oracle engineers, but it effects the >>> public hgforest script. >>> >>> When hgforest.sh is run with an addition argument to specify a closed >>> server, there is a problem/race between the creation of the directories >>> to hold nested repositories and the clone itself. These directories need >>> to be created before the clone command is executed, otherwise it will >>> fail, as below. >>> >>> The trivial fix is to back off these nested repos until their containing >>> directory exists. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>> >>> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >>> hotspot/test/closed deploy install sponsors pubs >>> >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>> Waiting 5 secs before spawning next background command. >>> .... >>> >>> >>> -Chris. > From erik.joelsson at oracle.com Mon Feb 4 11:42:51 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 Feb 2013 12:42:51 +0100 Subject: Review Request: 8007450: Add build support for different man pages for OpenJDK and OracleJDK Message-ID: <510F9EBB.4050202@oracle.com> Open part of this review: The docs team will start producing separate man pages for openjdk and oraclejdk. Here are the necessary changes to the makefiles to support this. http://cr.openjdk.java.net/~erikj/8007450/webrev.jdk.01/ /Erik From erik.joelsson at oracle.com Mon Feb 4 11:47:11 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 Feb 2013 12:47:11 +0100 Subject: Review Request: 8007450: Add build support for different man pages for OpenJDK and OracleJDK In-Reply-To: <510F9EBB.4050202@oracle.com> References: <510F9EBB.4050202@oracle.com> Message-ID: <510F9FBF.2090900@oracle.com> I should add that this is for jdk7u, what used to be 14. On 2013-02-04 12:42, Erik Joelsson wrote: > Open part of this review: > > The docs team will start producing separate man pages for openjdk and > oraclejdk. Here are the necessary changes to the makefiles to support > this. > > http://cr.openjdk.java.net/~erikj/8007450/webrev.jdk.01/ > > /Erik From david.holmes at oracle.com Mon Feb 4 11:57:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Feb 2013 21:57:38 +1000 Subject: Review Request: 8007450: Add build support for different man pages for OpenJDK and OracleJDK In-Reply-To: <510F9EBB.4050202@oracle.com> References: <510F9EBB.4050202@oracle.com> Message-ID: <510FA232.1070706@oracle.com> Hi Erik, Can you use $(CLOSED_PLATFORM_SOURCE) instead of hardwiring src/closed/? In theory it should be possible to relocate the "closed" repo and still have things work (by changing one definition). David On 4/02/2013 9:42 PM, Erik Joelsson wrote: > Open part of this review: > > The docs team will start producing separate man pages for openjdk and > oraclejdk. Here are the necessary changes to the makefiles to support this. > > http://cr.openjdk.java.net/~erikj/8007450/webrev.jdk.01/ > > /Erik From erik.joelsson at oracle.com Mon Feb 4 14:03:18 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 04 Feb 2013 14:03:18 +0000 Subject: hg: jdk8/build: 2 new changesets Message-ID: <20130204140319.4213D477DF@hg.openjdk.java.net> Changeset: 339e4df096a2 Author: erikj Date: 2013-02-04 10:53 +0100 URL: http://hg.openjdk.java.net/jdk8/build/rev/339e4df096a2 8007093: build-infra: Make should fail if spec is older than configure files Reviewed-by: tbell ! common/makefiles/Main.gmk Changeset: dea045cc48ca Author: erikj Date: 2013-02-04 11:02 +0100 URL: http://hg.openjdk.java.net/jdk8/build/rev/dea045cc48ca 8007275: build-infra: Create final-images target Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/makefiles/Jprt.gmk From erik.joelsson at oracle.com Mon Feb 4 14:03:30 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 04 Feb 2013 14:03:30 +0000 Subject: hg: jdk8/build/jdk: 8007268: build-infra: configure reports Solaris needs gcc for deploy, but logs don't indicate it's used. Message-ID: <20130204140413.4F081477E0@hg.openjdk.java.net> Changeset: 5692ebe15321 Author: erikj Date: 2013-02-04 10:58 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5692ebe15321 8007268: build-infra: configure reports Solaris needs gcc for deploy, but logs don't indicate it's used. Reviewed-by: tbell, katleman ! make/common/shared/Sanity.gmk From erik.joelsson at oracle.com Mon Feb 4 14:06:41 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 Feb 2013 15:06:41 +0100 Subject: Review Request: 8007450: Add build support for different man pages for OpenJDK and OracleJDK In-Reply-To: <510FA232.1070706@oracle.com> References: <510F9EBB.4050202@oracle.com> <510FA232.1070706@oracle.com> Message-ID: <510FC071.4050509@oracle.com> CLOSED_PLATFORM_SRC can't be used in this case since it points to the solaris directory for linux. I changed to at least use CLOSED_SRC instead. Verified on both solaris and linux, open and closed. http://cr.openjdk.java.net/~erikj/8007450/webrev.jdk.02/ /Erik On 2013-02-04 12:57, David Holmes wrote: > Hi Erik, > > Can you use $(CLOSED_PLATFORM_SOURCE) instead of hardwiring > src/closed/? In theory it should be possible to relocate the > "closed" repo and still have things work (by changing one definition). > > David > > On 4/02/2013 9:42 PM, Erik Joelsson wrote: >> Open part of this review: >> >> The docs team will start producing separate man pages for openjdk and >> oraclejdk. Here are the necessary changes to the makefiles to support >> this. >> >> http://cr.openjdk.java.net/~erikj/8007450/webrev.jdk.01/ >> >> /Erik From tim.bell at oracle.com Mon Feb 4 15:43:34 2013 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 04 Feb 2013 07:43:34 -0800 Subject: Review Request: 8007450: Add build support for different man pages for OpenJDK and OracleJDK In-Reply-To: <510FC071.4050509@oracle.com> References: <510F9EBB.4050202@oracle.com> <510FA232.1070706@oracle.com> <510FC071.4050509@oracle.com> Message-ID: <510FD726.5060409@oracle.com> Hi Erik: > CLOSED_PLATFORM_SRC can't be used in this case since it points to the > solaris directory for linux. I changed to at least use CLOSED_SRC > instead. Verified on both solaris and linux, open and closed. > > http://cr.openjdk.java.net/~erikj/8007450/webrev.jdk.02/ Looks good. Tim > /Erik > > On 2013-02-04 12:57, David Holmes wrote: >> Hi Erik, >> >> Can you use $(CLOSED_PLATFORM_SOURCE) instead of hardwiring >> src/closed/? In theory it should be possible to relocate the >> "closed" repo and still have things work (by changing one definition). >> >> David >> >> On 4/02/2013 9:42 PM, Erik Joelsson wrote: >>> Open part of this review: >>> >>> The docs team will start producing separate man pages for openjdk and >>> oraclejdk. Here are the necessary changes to the makefiles to >>> support this. >>> >>> http://cr.openjdk.java.net/~erikj/8007450/webrev.jdk.01/ >>> >>> /Erik From kelly.ohair at oracle.com Mon Feb 4 17:14:21 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 4 Feb 2013 09:14:21 -0800 Subject: Review Request: 8007450: Add build support for different man pages for OpenJDK and OracleJDK In-Reply-To: <510FC071.4050509@oracle.com> References: <510F9EBB.4050202@oracle.com> <510FA232.1070706@oracle.com> <510FC071.4050509@oracle.com> Message-ID: <949AB9A4-0B22-4918-A2FA-6D0B26817929@oracle.com> Looks ok to me too. -kto On Feb 4, 2013, at 6:06 AM, Erik Joelsson wrote: > CLOSED_PLATFORM_SRC can't be used in this case since it points to the solaris directory for linux. I changed to at least use CLOSED_SRC instead. Verified on both solaris and linux, open and closed. > > http://cr.openjdk.java.net/~erikj/8007450/webrev.jdk.02/ > > /Erik > > On 2013-02-04 12:57, David Holmes wrote: >> Hi Erik, >> >> Can you use $(CLOSED_PLATFORM_SOURCE) instead of hardwiring src/closed/? In theory it should be possible to relocate the "closed" repo and still have things work (by changing one definition). >> >> David >> >> On 4/02/2013 9:42 PM, Erik Joelsson wrote: >>> Open part of this review: >>> >>> The docs team will start producing separate man pages for openjdk and >>> oraclejdk. Here are the necessary changes to the makefiles to support this. >>> >>> http://cr.openjdk.java.net/~erikj/8007450/webrev.jdk.01/ >>> >>> /Erik From kelly.ohair at oracle.com Mon Feb 4 17:21:37 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 4 Feb 2013 09:21:37 -0800 Subject: problem building OpenJDK on Windows 7 in langtools In-Reply-To: <1AC3281AD57A34468B9879C754022CAF05F13E7DE2@exchange.vocera.local> References: <1AC3281AD57A34468B9879C754022CAF05F13E7DE2@exchange.vocera.local> Message-ID: All paths supplied to the ALT variables and things like ANT_HOME need to be in the c:/ style paths. Ignore what the ant scripts echo in error messages, or compiler warnings, that's a red herring. So ALT_BOOTDIR in your case needs to be set to C:/OpenJDK/jdk-6u37 and ANT_HOME needs to be C:/OpenJDK/apache-ant-1.8.4 The ant and java.exe processes will not understand /cygdrive/ paths, and use of \ in paths will cause all kinds of shell issues, just like using spaces in paths will. Please read http://hg.openjdk.java.net/jdk7u/jdk7u-dev/raw-file/tip/README-builds.html#windows -kto On Feb 3, 2013, at 11:32 PM, Randy Nielsen wrote: > I'm trying to build 64 bit java 7 on 64 bit Windows 7 with Cygwin, using instructions from http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html > > I built environment variables in Windows then simply typed "make". I get pass the sanity make sanity but choke fairly early in the langtools make. > Full console output is at the end of the post. Here are the failure lines: > > > -def-pcompile: > [javac] Compiling 2 source files to C:\OpenJDK\jdk7-source\openjdk\build\windows-amd64\langtools\build\toolclasses > > BUILD FAILED > C:\OpenJDK\jdk7-source\openjdk\langtools\make\build.xml:860: Error running \cygdrive\c\OpenJDK\jdk-6u37\bin\javac compiler > > Total time: 0 seconds > make[2]: *** [build] Error 1 > make[2]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk/langtools/make' > make[1]: *** [langtools-build] Error 2 > make[1]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk' > make: *** [build_product_image] Error 2 > > > I'm puzzled because the failure message appears to show that the build is trying to run javac with "\" separators instead of "/": > \cygdrive\c\OpenJDK\jdk-6u37\bin\javac > > Invoking /cygdrive/c/OpenJDK/jdk-6u37/bin/javac works, producing the usual usage lines. > > On the surface the problem is \ vs. / but how can that be since ALT_BOOTDIR=/cygdrive/c/OpenJDK/jdk-6u37? So I could dig deeper I assumed that > the problem was something else but can find no log file showing the parameters that javac was called with. > > Can anyone help? > > Thanks, > > Randy > > HERE IS THE FULL CYGWIN CONSOLE OUTPUT: > > Administrator at WIN-R7HSHTAIIHC ~ > $ cd /cygdrive/c/OpenJDK/jdk7-source/openjdk > > Administrator at WIN-R7HSHTAIIHC /cygdrive/c/OpenJDK/jdk7-source/openjdk > $ make > cygwin warning: > MS-DOS style path detected: C:/PROGRA~2/MI4ADD~1 > Preferred POSIX equivalent is: /cygdrive/c/PROGRA~2/MI4ADD~1 > CYGWIN environment variable option "nodosfilewarning" turns off this warning. > Consult the user's guide for more details about POSIX paths: > http://cygwin.com/cygwin-ug-net/using.html#using-pathnames > ( cd ./jdk/make && \ > make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk JDK_MAKE_SHARED_DIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-administrator_2013_02_03_23_27-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="/cygdrive/c/OpenJDK/apache-ant-1.8.4" ALT_OUTPUTDIR=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 ALT_LANGTOOLS_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/dist ALT_CORBA_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/corba/dist ALT_JAXP_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxp/dist ALT_JAXWS_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxws/dist ALT_HOTSPOT_IMPORT_PATH=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import BUILD_HOTSPOT=true ; ) > make[1]: Entering directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk/jdk/make' > make[1]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk/jdk/make' > > Build Machine Information: > build machine = WIN-R7HSHTAIIHC > > Build Directory Structure: > CWD = /cygdrive/c/OpenJDK/jdk7-source/openjdk > TOPDIR = . > LANGTOOLS_TOPDIR = ./langtools > JAXP_TOPDIR = ./jaxp > JAXWS_TOPDIR = ./jaxws > CORBA_TOPDIR = ./corba > HOTSPOT_TOPDIR = ./hotspot > JDK_TOPDIR = ./jdk > > Build Directives: > BUILD_LANGTOOLS = true > BUILD_JAXP = true > BUILD_JAXWS = true > BUILD_CORBA = true > BUILD_HOTSPOT = true > BUILD_JDK = true > DEBUG_CLASSFILES = > DEBUG_BINARIES = > > Hotspot Settings: > HOTSPOT_BUILD_JOBS = > HOTSPOT_OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/outputdir > HOTSPOT_EXPORT_PATH = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import > > > > > Bootstrap Settings: > BOOTDIR = /cygdrive/c/OpenJDK/jdk-6u37 > ALT_BOOTDIR = /cygdrive/c/OpenJDK/jdk-6u37 > BOOT_VER = 1.6.0 [requires at least 1.6] > OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 > ALT_OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 > ABS_OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 > > Build Tool Settings: > SLASH_JAVA = J: > ALT_SLASH_JAVA = > VARIANT = OPT > JDK_DEVTOOLS_DIR = J:/devtools > ALT_JDK_DEVTOOLS_DIR = > ANT_HOME = /cygdrive/c/OpenJDK/apache-ant-1.8.4 > UNIXCOMMAND_PATH = /usr/bin/ > ALT_UNIXCOMMAND_PATH = > COMPILER_PATH = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/ > ALT_COMPILER_PATH = > DEVTOOLS_PATH = /usr/bin/ > ALT_DEVTOOLS_PATH = > MSVCRNN_DLL_PATH = C:/Windows/system32 > ALT_MSVCRNN_DLL_PATH = > INCLUDE = C:/msvs2012/VC/include;C:/MSSDKWIN7/Windows/v7.1/Include > LIB = C:/msvs2012/VC/lib/amd64;C:/MSSDKWIN7/Windows/v7.1/Lib/x64 > COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) > COMPILER_VERSION = VS2010 > CC_VER = 16.00.30319.01 [requires at least 16.00.30319.01] > ZIP_VER = 3.0 [requires at least 2.2] > UNZIP_VER = 6.00 [requires at least 5.12] > LINK_VER = 10.00.30319.01 [requires at least 10.00.30319.01] > CC = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/cl > LINK = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/link > DUMPBIN = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe > ANT_VER = 1.8.4 [requires at least 1.7.1] > TEMPDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp > > Build Directives: > OPENJDK = true > USE_HOTSPOT_INTERPRETER_MODE = > PEDANTIC = > DEV_ONLY = > NO_DOCS = > NO_IMAGES = > TOOLS_ONLY = > INSANE = > COMPILE_APPROACH = normal > FASTDEBUG = > COMPILER_WARNINGS_FATAL = false > COMPILER_WARNING_LEVEL = 3 > SHOW_ALL_WARNINGS = false > INCREMENTAL_BUILD = false > CC_HIGHEST_OPT = > CC_HIGHER_OPT = > CC_LOWER_OPT = > CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE > CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE > BOOT_JAVA_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m > BOOT_JAVAC_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/javac -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 -XDignore.symbol.file=true > BOOT_JAR_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/jar > BOOT_JARSIGNER_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/jarsigner > > Build Platform Settings: > USER = Administrator > PLATFORM = windows > ARCH = amd64 > LIBARCH = amd64 > ARCH_FAMILY = amd64 > ARCH_DATA_MODEL = 64 > ARCHPROP = amd64 > PROCESSOR_ARCHITECTURE = x86 > PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 26 Stepping 5, GenuineIntel > USING_CYGWIN = true > CYGWIN_VER = 6.1 [requires at least 4.0] > CYGPATH_CMD = cygpath -a -s -m > OS_VERSION = 6.1 [requires at least 5.2] > OS_VARIANT_NAME = > OS_VARIANT_VERSION = 6.1 > MB_OF_MEMORY = 1023 > > GNU Make Settings: > MAKE = make > MAKE_VER = 3.82 [requires at least 3.81] > MAKECMDGOALS = sanity > MAKEFLAGS = w > SHELL = /bin/sh > > Target Build Versions: > JDK_VERSION = 1.7.0 > MILESTONE = internal > RELEASE = 1.7.0-internal > FULL_VERSION = 1.7.0-internal-administrator_2013_02_03_23_27-b00 > BUILD_NUMBER = b00 > > External File/Binary Locations: > USRJDKINSTANCES_PATH = C:/PROGRA~1/Java > BUILD_JDK_IMPORT_PATH = J:/re/jdk/1.7.0/promoted/latest/binaries > ALT_BUILD_JDK_IMPORT_PATH = > JDK_IMPORT_PATH = J:/re/jdk/1.7.0/promoted/latest/binaries/windows-amd64 > ALT_JDK_IMPORT_PATH = > LANGTOOLS_DIST = > ALT_LANGTOOLS_DIST = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/dist > CORBA_DIST = > ALT_CORBA_DIST = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/corba/dist > JAXP_DIST = > ALT_JAXP_DIST = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxp/dist > JAXWS_DIST = > ALT_JAXWS_DIST = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxws/dist > HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR > ALT_HOTSPOT_DOCS_IMPORT_PATH = > HOTSPOT_IMPORT_PATH = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import > ALT_HOTSPOT_IMPORT_PATH = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import > HOTSPOT_SERVER_PATH = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import/jre/bin/server > ALT_HOTSPOT_SERVER_PATH = > HOTSPOT_LIB_PATH = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import/lib > ALT_HOTSPOT_LIB_PATH = > DXSDK_VER = 0x0900 > DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 > ALT_DXSDK_PATH = > DXSDK_INCLUDE_PATH = C:/PROGRA~2/MI4ADD~1/Include > ALT_DXSDK_INCLUDE_PATH = > DXSDK_LIB_PATH = C:/PROGRA~2/MI4ADD~1/Lib/x64 > ALT_DXSDK_LIB_PATH = > WINDOWSSDKDIR = c:\MSSDKWIN7\Windows > 7.1/ > ALT_WINDOWSSDKDIR = > RC = c:\MSSDKWIN7\Windows > 7.1//Bin/x64/RC.Exe > REBASE = c:\MSSDKWIN7\Windows > 7.1//Bin/x64/ReBase.Exe > CACERTS_FILE = ./../src/share/lib/security/cacerts > ALT_CACERTS_FILE = > > OpenJDK-specific settings: > FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include > ALT_FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include > FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 > ALT_FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 > > Previous JDK Settings: > PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE > ALT_PREVIOUS_RELEASE_PATH = > PREVIOUS_JDK_VERSION = 1.6.0 > ALT_PREVIOUS_JDK_VERSION = > PREVIOUS_JDK_FILE = > ALT_PREVIOUS_JDK_FILE = > PREVIOUS_JRE_FILE = > ALT_PREVIOUS_JRE_FILE = > PREVIOUS_RELEASE_IMAGE = /cygdrive/c/OpenJDK/jdk-6u37 > ALT_PREVIOUS_RELEASE_IMAGE = > > > Sanity check passed. > make \ > SKIP_FASTDEBUG_BUILD=true \ > SKIP_DEBUG_BUILD=true \ > \ > generic_build_repo_series > make[1]: Entering directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk' > /usr/bin/mkdir -p ./build/windows-amd64/j2sdk-image > /usr/bin/mkdir -p C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools > > > ######################################################################## > ######################################################################## > ##### Entering langtools for target(s) all ##### > ######################################################################## > > (cd ./langtools/make && \ > make JDK_TOPDIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk JDK_MAKE_SHARED_DIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-administrator_2013_02_03_23_27-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="/cygdrive/c/OpenJDK/apache-ant-1.8.4" ALT_OUTPUTDIR=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools ALT_BOOTDIR=/cygdrive/c/OpenJDK/jdk-6u37 all) > make[2]: Entering directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk/langtools/make' > JAVA_HOME=/cygdrive/c/OpenJDK/jdk-6u37 ANT_OPTS=-Djava.io.tmpdir='C:/OpenJDK/JDK7-S~1/openjdk/build/WINDOW~1/LANGTO~1/build/ant-tmp' /cygdrive/c/OpenJDK/apache-ant-1.8.4/bin/ant -Djdk.version=1.7.0 -Dfull.version='1.7.0-internal-administrator_2013_02_03_23_27-b00' -Dmilestone=internal -Dbuild.number=b00 -Djavac.target=7 -Djavac.source=7 -Dboot.java.home=/cygdrive/c/OpenJDK/jdk-6u37 -Dimport.jdk=C:/OpenJDK/JDK7-S~1/openjdk/jdk -Dbuild.dir=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/build -Ddist.dir=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/dist build > Buildfile: C:\OpenJDK\jdk7-source\openjdk\langtools\make\build.xml > > -def-pcompile: > [javac] Compiling 2 source files to C:\OpenJDK\jdk7-source\openjdk\build\windows-amd64\langtools\build\toolclasses > > BUILD FAILED > C:\OpenJDK\jdk7-source\openjdk\langtools\make\build.xml:860: Error running \cygdrive\c\OpenJDK\jdk-6u37\bin\javac compiler > > Total time: 0 seconds > make[2]: *** [build] Error 1 > make[2]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk/langtools/make' > make[1]: *** [langtools-build] Error 2 > make[1]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk' > make: *** [build_product_image] Error 2 > > Administrator at WIN-R7HSHTAIIHC /cygdrive/c/OpenJDK/jdk7-source/openjdk > $ > > > > > > > > > > From kelly.ohair at oracle.com Mon Feb 4 17:52:40 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 4 Feb 2013 09:52:40 -0800 Subject: problem building OpenJDK on Windows 7 in langtools In-Reply-To: References: <1AC3281AD57A34468B9879C754022CAF05F13E7DE2@exchange.vocera.local> Message-ID: Also, use of ant 1.8.4 might work fine, but we have always advised ant 1.7.1. Some of the bug fixes in ant 1.8+ have actually caused a few problems in older ant scripts (perhaps buggy scripts), just so you are warned. Dito with jdk6, we try and use jdk6u18, but newer versions should work, that's much less of an issue than the ant version. -kto On Feb 4, 2013, at 9:21 AM, Kelly O'Hair wrote: > > All paths supplied to the ALT variables and things like ANT_HOME need to be in the c:/ style paths. > Ignore what the ant scripts echo in error messages, or compiler warnings, that's a red herring. > > So ALT_BOOTDIR in your case needs to be set to C:/OpenJDK/jdk-6u37 > and ANT_HOME needs to be C:/OpenJDK/apache-ant-1.8.4 > > The ant and java.exe processes will not understand /cygdrive/ paths, and use of \ in paths will cause > all kinds of shell issues, just like using spaces in paths will. > > Please read http://hg.openjdk.java.net/jdk7u/jdk7u-dev/raw-file/tip/README-builds.html#windows > > -kto > > On Feb 3, 2013, at 11:32 PM, Randy Nielsen wrote: > >> I'm trying to build 64 bit java 7 on 64 bit Windows 7 with Cygwin, using instructions from http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html >> >> I built environment variables in Windows then simply typed "make". I get pass the sanity make sanity but choke fairly early in the langtools make. >> Full console output is at the end of the post. Here are the failure lines: >> >> >> -def-pcompile: >> [javac] Compiling 2 source files to C:\OpenJDK\jdk7-source\openjdk\build\windows-amd64\langtools\build\toolclasses >> >> BUILD FAILED >> C:\OpenJDK\jdk7-source\openjdk\langtools\make\build.xml:860: Error running \cygdrive\c\OpenJDK\jdk-6u37\bin\javac compiler >> >> Total time: 0 seconds >> make[2]: *** [build] Error 1 >> make[2]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk/langtools/make' >> make[1]: *** [langtools-build] Error 2 >> make[1]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk' >> make: *** [build_product_image] Error 2 >> >> >> I'm puzzled because the failure message appears to show that the build is trying to run javac with "\" separators instead of "/": >> \cygdrive\c\OpenJDK\jdk-6u37\bin\javac >> >> Invoking /cygdrive/c/OpenJDK/jdk-6u37/bin/javac works, producing the usual usage lines. >> >> On the surface the problem is \ vs. / but how can that be since ALT_BOOTDIR=/cygdrive/c/OpenJDK/jdk-6u37? So I could dig deeper I assumed that >> the problem was something else but can find no log file showing the parameters that javac was called with. >> >> Can anyone help? >> >> Thanks, >> >> Randy >> >> HERE IS THE FULL CYGWIN CONSOLE OUTPUT: >> >> Administrator at WIN-R7HSHTAIIHC ~ >> $ cd /cygdrive/c/OpenJDK/jdk7-source/openjdk >> >> Administrator at WIN-R7HSHTAIIHC /cygdrive/c/OpenJDK/jdk7-source/openjdk >> $ make >> cygwin warning: >> MS-DOS style path detected: C:/PROGRA~2/MI4ADD~1 >> Preferred POSIX equivalent is: /cygdrive/c/PROGRA~2/MI4ADD~1 >> CYGWIN environment variable option "nodosfilewarning" turns off this warning. >> Consult the user's guide for more details about POSIX paths: >> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames >> ( cd ./jdk/make && \ >> make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk JDK_MAKE_SHARED_DIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-administrator_2013_02_03_23_27-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="/cygdrive/c/OpenJDK/apache-ant-1.8.4" ALT_OUTPUTDIR=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 ALT_LANGTOOLS_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/dist ALT_CORBA_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/corba/dist ALT_JAXP_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxp/dist ALT_JAXWS_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxws/dist ALT_HOTSPOT_IMPORT_PATH=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import BUILD_HOTSPOT=true ; ) >> make[1]: Entering directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk/jdk/make' >> make[1]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk/jdk/make' >> >> Build Machine Information: >> build machine = WIN-R7HSHTAIIHC >> >> Build Directory Structure: >> CWD = /cygdrive/c/OpenJDK/jdk7-source/openjdk >> TOPDIR = . >> LANGTOOLS_TOPDIR = ./langtools >> JAXP_TOPDIR = ./jaxp >> JAXWS_TOPDIR = ./jaxws >> CORBA_TOPDIR = ./corba >> HOTSPOT_TOPDIR = ./hotspot >> JDK_TOPDIR = ./jdk >> >> Build Directives: >> BUILD_LANGTOOLS = true >> BUILD_JAXP = true >> BUILD_JAXWS = true >> BUILD_CORBA = true >> BUILD_HOTSPOT = true >> BUILD_JDK = true >> DEBUG_CLASSFILES = >> DEBUG_BINARIES = >> >> Hotspot Settings: >> HOTSPOT_BUILD_JOBS = >> HOTSPOT_OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/outputdir >> HOTSPOT_EXPORT_PATH = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import >> >> >> >> >> Bootstrap Settings: >> BOOTDIR = /cygdrive/c/OpenJDK/jdk-6u37 >> ALT_BOOTDIR = /cygdrive/c/OpenJDK/jdk-6u37 >> BOOT_VER = 1.6.0 [requires at least 1.6] >> OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 >> ALT_OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 >> ABS_OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64 >> >> Build Tool Settings: >> SLASH_JAVA = J: >> ALT_SLASH_JAVA = >> VARIANT = OPT >> JDK_DEVTOOLS_DIR = J:/devtools >> ALT_JDK_DEVTOOLS_DIR = >> ANT_HOME = /cygdrive/c/OpenJDK/apache-ant-1.8.4 >> UNIXCOMMAND_PATH = /usr/bin/ >> ALT_UNIXCOMMAND_PATH = >> COMPILER_PATH = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/ >> ALT_COMPILER_PATH = >> DEVTOOLS_PATH = /usr/bin/ >> ALT_DEVTOOLS_PATH = >> MSVCRNN_DLL_PATH = C:/Windows/system32 >> ALT_MSVCRNN_DLL_PATH = >> INCLUDE = C:/msvs2012/VC/include;C:/MSSDKWIN7/Windows/v7.1/Include >> LIB = C:/msvs2012/VC/lib/amd64;C:/MSSDKWIN7/Windows/v7.1/Lib/x64 >> COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) >> COMPILER_VERSION = VS2010 >> CC_VER = 16.00.30319.01 [requires at least 16.00.30319.01] >> ZIP_VER = 3.0 [requires at least 2.2] >> UNZIP_VER = 6.00 [requires at least 5.12] >> LINK_VER = 10.00.30319.01 [requires at least 10.00.30319.01] >> CC = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/cl >> LINK = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/link >> DUMPBIN = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe >> ANT_VER = 1.8.4 [requires at least 1.7.1] >> TEMPDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp >> >> Build Directives: >> OPENJDK = true >> USE_HOTSPOT_INTERPRETER_MODE = >> PEDANTIC = >> DEV_ONLY = >> NO_DOCS = >> NO_IMAGES = >> TOOLS_ONLY = >> INSANE = >> COMPILE_APPROACH = normal >> FASTDEBUG = >> COMPILER_WARNINGS_FATAL = false >> COMPILER_WARNING_LEVEL = 3 >> SHOW_ALL_WARNINGS = false >> INCREMENTAL_BUILD = false >> CC_HIGHEST_OPT = >> CC_HIGHER_OPT = >> CC_LOWER_OPT = >> CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >> CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >> BOOT_JAVA_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m >> BOOT_JAVAC_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/javac -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 -XDignore.symbol.file=true >> BOOT_JAR_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/jar >> BOOT_JARSIGNER_CMD = /cygdrive/c/OpenJDK/jdk-6u37/bin/jarsigner >> >> Build Platform Settings: >> USER = Administrator >> PLATFORM = windows >> ARCH = amd64 >> LIBARCH = amd64 >> ARCH_FAMILY = amd64 >> ARCH_DATA_MODEL = 64 >> ARCHPROP = amd64 >> PROCESSOR_ARCHITECTURE = x86 >> PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 26 Stepping 5, GenuineIntel >> USING_CYGWIN = true >> CYGWIN_VER = 6.1 [requires at least 4.0] >> CYGPATH_CMD = cygpath -a -s -m >> OS_VERSION = 6.1 [requires at least 5.2] >> OS_VARIANT_NAME = >> OS_VARIANT_VERSION = 6.1 >> MB_OF_MEMORY = 1023 >> >> GNU Make Settings: >> MAKE = make >> MAKE_VER = 3.82 [requires at least 3.81] >> MAKECMDGOALS = sanity >> MAKEFLAGS = w >> SHELL = /bin/sh >> >> Target Build Versions: >> JDK_VERSION = 1.7.0 >> MILESTONE = internal >> RELEASE = 1.7.0-internal >> FULL_VERSION = 1.7.0-internal-administrator_2013_02_03_23_27-b00 >> BUILD_NUMBER = b00 >> >> External File/Binary Locations: >> USRJDKINSTANCES_PATH = C:/PROGRA~1/Java >> BUILD_JDK_IMPORT_PATH = J:/re/jdk/1.7.0/promoted/latest/binaries >> ALT_BUILD_JDK_IMPORT_PATH = >> JDK_IMPORT_PATH = J:/re/jdk/1.7.0/promoted/latest/binaries/windows-amd64 >> ALT_JDK_IMPORT_PATH = >> LANGTOOLS_DIST = >> ALT_LANGTOOLS_DIST = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/dist >> CORBA_DIST = >> ALT_CORBA_DIST = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/corba/dist >> JAXP_DIST = >> ALT_JAXP_DIST = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxp/dist >> JAXWS_DIST = >> ALT_JAXWS_DIST = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxws/dist >> HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR >> ALT_HOTSPOT_DOCS_IMPORT_PATH = >> HOTSPOT_IMPORT_PATH = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import >> ALT_HOTSPOT_IMPORT_PATH = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import >> HOTSPOT_SERVER_PATH = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import/jre/bin/server >> ALT_HOTSPOT_SERVER_PATH = >> HOTSPOT_LIB_PATH = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import/lib >> ALT_HOTSPOT_LIB_PATH = >> DXSDK_VER = 0x0900 >> DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 >> ALT_DXSDK_PATH = >> DXSDK_INCLUDE_PATH = C:/PROGRA~2/MI4ADD~1/Include >> ALT_DXSDK_INCLUDE_PATH = >> DXSDK_LIB_PATH = C:/PROGRA~2/MI4ADD~1/Lib/x64 >> ALT_DXSDK_LIB_PATH = >> WINDOWSSDKDIR = c:\MSSDKWIN7\Windows >> 7.1/ >> ALT_WINDOWSSDKDIR = >> RC = c:\MSSDKWIN7\Windows >> 7.1//Bin/x64/RC.Exe >> REBASE = c:\MSSDKWIN7\Windows >> 7.1//Bin/x64/ReBase.Exe >> CACERTS_FILE = ./../src/share/lib/security/cacerts >> ALT_CACERTS_FILE = >> >> OpenJDK-specific settings: >> FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include >> ALT_FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include >> FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 >> ALT_FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 >> >> Previous JDK Settings: >> PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE >> ALT_PREVIOUS_RELEASE_PATH = >> PREVIOUS_JDK_VERSION = 1.6.0 >> ALT_PREVIOUS_JDK_VERSION = >> PREVIOUS_JDK_FILE = >> ALT_PREVIOUS_JDK_FILE = >> PREVIOUS_JRE_FILE = >> ALT_PREVIOUS_JRE_FILE = >> PREVIOUS_RELEASE_IMAGE = /cygdrive/c/OpenJDK/jdk-6u37 >> ALT_PREVIOUS_RELEASE_IMAGE = >> >> >> Sanity check passed. >> make \ >> SKIP_FASTDEBUG_BUILD=true \ >> SKIP_DEBUG_BUILD=true \ >> \ >> generic_build_repo_series >> make[1]: Entering directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk' >> /usr/bin/mkdir -p ./build/windows-amd64/j2sdk-image >> /usr/bin/mkdir -p C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools >> >> >> ######################################################################## >> ######################################################################## >> ##### Entering langtools for target(s) all ##### >> ######################################################################## >> >> (cd ./langtools/make && \ >> make JDK_TOPDIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk JDK_MAKE_SHARED_DIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-administrator_2013_02_03_23_27-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="/cygdrive/c/OpenJDK/apache-ant-1.8.4" ALT_OUTPUTDIR=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools ALT_BOOTDIR=/cygdrive/c/OpenJDK/jdk-6u37 all) >> make[2]: Entering directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk/langtools/make' >> JAVA_HOME=/cygdrive/c/OpenJDK/jdk-6u37 ANT_OPTS=-Djava.io.tmpdir='C:/OpenJDK/JDK7-S~1/openjdk/build/WINDOW~1/LANGTO~1/build/ant-tmp' /cygdrive/c/OpenJDK/apache-ant-1.8.4/bin/ant -Djdk.version=1.7.0 -Dfull.version='1.7.0-internal-administrator_2013_02_03_23_27-b00' -Dmilestone=internal -Dbuild.number=b00 -Djavac.target=7 -Djavac.source=7 -Dboot.java.home=/cygdrive/c/OpenJDK/jdk-6u37 -Dimport.jdk=C:/OpenJDK/JDK7-S~1/openjdk/jdk -Dbuild.dir=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/build -Ddist.dir=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/dist build >> Buildfile: C:\OpenJDK\jdk7-source\openjdk\langtools\make\build.xml >> >> -def-pcompile: >> [javac] Compiling 2 source files to C:\OpenJDK\jdk7-source\openjdk\build\windows-amd64\langtools\build\toolclasses >> >> BUILD FAILED >> C:\OpenJDK\jdk7-source\openjdk\langtools\make\build.xml:860: Error running \cygdrive\c\OpenJDK\jdk-6u37\bin\javac compiler >> >> Total time: 0 seconds >> make[2]: *** [build] Error 1 >> make[2]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk/langtools/make' >> make[1]: *** [langtools-build] Error 2 >> make[1]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk' >> make: *** [build_product_image] Error 2 >> >> Administrator at WIN-R7HSHTAIIHC /cygdrive/c/OpenJDK/jdk7-source/openjdk >> $ >> >> >> >> >> >> >> >> >> >> > From kelly.ohair at oracle.com Mon Feb 4 18:15:51 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 4 Feb 2013 10:15:51 -0800 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510BD3E6.1090103@oracle.com> References: <510BD3E6.1090103@oracle.com> Message-ID: Looks fine to me. -kto On Feb 1, 2013, at 6:40 AM, Chris Hegarty wrote: > [ to build-dev and core-libs-dev, expect reviewer from either, but will integrate through jdk8/tl ] > > This issue is mainly of interest to Oracle engineers, but it effects the public hgforest script. > > When hgforest.sh is run with an addition argument to specify a closed server, there is a problem/race between the creation of the directories to hold nested repositories and the clone itself. These directories need to be created before the clone command is executed, otherwise it will fail, as below. > > The trivial fix is to back off these nested repos until their containing directory exists. > > Webrev: > http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ > > sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log > # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs > > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u /java/devtools/sparc/mercurial/latest/bin/hg clone http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed > jdk/src/closed: abort: No such file or directory: jdk/src/closed > jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u /java/devtools/sparc/mercurial/latest/bin/hg clone http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed > jdk/make/closed: abort: No such file or directory: jdk/make/closed > Waiting 5 secs before spawning next background command. > .... > > > -Chris. From kelly.ohair at oracle.com Mon Feb 4 18:23:33 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 4 Feb 2013 10:23:33 -0800 Subject: Updating jdk8 README files Message-ID: <382C15F4-72D8-44D3-A2A0-CC0E132A65F2@oracle.com> FYI... I am in the process of updating the OpenJDK8 build readme files. I'm working in the build-infra/jdk8 forest with these files and will update the jdk8/build forest when they near completion. In the meantime, anyone wishing to view the current state can view them through the build-infra/jdk8 forest. I am pretty much done with this one: http://hg.openjdk.java.net/build-infra/jdk8/raw-file/tip/README But still working on README-builds.html, moving a great deal of the information to Appendix's, which still need to be organized, merged, deleted, cleaned up, etc. http://hg.openjdk.java.net/build-infra/jdk8/raw-file/tip/README-builds.html Please send me any comments or observations. -kto From chris.hegarty at oracle.com Mon Feb 4 20:32:44 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 4 Feb 2013 20:32:44 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <51100DC3.4090007@oracle.com> References: <510BD3E6.1090103@oracle.com> <510C43A8.7040805@oracle.com> <51100DC3.4090007@oracle.com> Message-ID: <4BDAEAC3-6B3C-471E-8BBA-3B6794C0B7A6@oracle.com> On 4 Feb 2013, at 19:36, Ioi Lam wrote: > How about adding a message to indicate the sleep, just in case the directory is never created for whatever reason. If you don't like too many such messages, you can print the message after the initial wait. I understand the reason for your suggestion, but in my environment it can take more than a minute before these directories are created, which will be very noisy with six of these nested repos. If these repos are never created then you have bigger problems, disk space, I/O, etc, which such be indicated by the process that encounters the problem. -Chris. > > 177 while [ ! -d "$path" ] ## nested repo, ensure containing dir exists > 178 do > 179 sleep 5 > if[ ! -d "$path" ] ; then > echo "Sleeping to wait for '$path' to be created"; > fi > 180 done > 181 fi > > - Ioi > > On 02/01/2013 02:37 PM, David Holmes wrote: >> Hi Chris, >> >> On 2/02/2013 12:40 AM, Chris Hegarty wrote: >>> [ to build-dev and core-libs-dev, expect reviewer from either, but will >>> integrate through jdk8/tl ] >>> >>> This issue is mainly of interest to Oracle engineers, but it effects the >>> public hgforest script. >>> >>> When hgforest.sh is run with an addition argument to specify a closed >>> server, there is a problem/race between the creation of the directories >>> to hold nested repositories and the clone itself. These directories need >>> to be created before the clone command is executed, otherwise it will >>> fail, as below. >> >> I think I reported this myself just last week - probably internally to build or build-infra. >> >> The weird thing is that based on the list of repos it shouldn't be grabbing the closed one yet. >> >>> The trivial fix is to back off these nested repos until their containing >>> directory exists. >> >> That seems to assume/require that the nested repo will always be later in the list. They happen to be but .... >> >> Workaround is to run get_source.sh twice first without the "extra base" then with it. >> >> David >> ----- >> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>> >>> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >>> hotspot/test/closed deploy install sponsors pubs >>> >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>> Waiting 5 secs before spawning next background command. >>> .... >>> >>> >>> -Chris. > From david.holmes at oracle.com Mon Feb 4 20:40:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Feb 2013 06:40:52 +1000 Subject: Review Request: 8007450: Add build support for different man pages for OpenJDK and OracleJDK In-Reply-To: <510FC071.4050509@oracle.com> References: <510F9EBB.4050202@oracle.com> <510FA232.1070706@oracle.com> <510FC071.4050509@oracle.com> Message-ID: <51101CD4.1090701@oracle.com> On 5/02/2013 12:06 AM, Erik Joelsson wrote: > CLOSED_PLATFORM_SRC can't be used in this case since it points to the > solaris directory for linux. I changed to at least use CLOSED_SRC > instead. Verified on both solaris and linux, open and closed. Thanks. David ----- > http://cr.openjdk.java.net/~erikj/8007450/webrev.jdk.02/ > > /Erik > > On 2013-02-04 12:57, David Holmes wrote: >> Hi Erik, >> >> Can you use $(CLOSED_PLATFORM_SOURCE) instead of hardwiring >> src/closed/? In theory it should be possible to relocate the >> "closed" repo and still have things work (by changing one definition). >> >> David >> >> On 4/02/2013 9:42 PM, Erik Joelsson wrote: >>> Open part of this review: >>> >>> The docs team will start producing separate man pages for openjdk and >>> oraclejdk. Here are the necessary changes to the makefiles to support >>> this. >>> >>> http://cr.openjdk.java.net/~erikj/8007450/webrev.jdk.01/ >>> >>> /Erik From ioi.lam at oracle.com Mon Feb 4 19:36:35 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 04 Feb 2013 11:36:35 -0800 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510C43A8.7040805@oracle.com> References: <510BD3E6.1090103@oracle.com> <510C43A8.7040805@oracle.com> Message-ID: <51100DC3.4090007@oracle.com> How about adding a message to indicate the sleep, just in case the directory is never created for whatever reason. If you don't like too many such messages, you can print the message after the initial wait. 177 while [ ! -d "$path" ] ## nested repo, ensure containing dir exists 178 do 179 sleep 5 if[ ! -d "$path" ] ; then echo "Sleeping to wait for '$path' to be created"; fi 180 done 181 fi - Ioi On 02/01/2013 02:37 PM, David Holmes wrote: > Hi Chris, > > On 2/02/2013 12:40 AM, Chris Hegarty wrote: >> [ to build-dev and core-libs-dev, expect reviewer from either, but will >> integrate through jdk8/tl ] >> >> This issue is mainly of interest to Oracle engineers, but it effects the >> public hgforest script. >> >> When hgforest.sh is run with an addition argument to specify a closed >> server, there is a problem/race between the creation of the directories >> to hold nested repositories and the clone itself. These directories need >> to be created before the clone command is executed, otherwise it will >> fail, as below. > > I think I reported this myself just last week - probably internally to > build or build-infra. > > The weird thing is that based on the list of repos it shouldn't be > grabbing the closed one yet. > >> The trivial fix is to back off these nested repos until their containing >> directory exists. > > That seems to assume/require that the nested repo will always be later > in the list. They happen to be but .... > > Workaround is to run get_source.sh twice first without the "extra > base" then with it. > > David > ----- > >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >> >> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >> hotspot/test/closed deploy install sponsors pubs >> >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >> jdk/src/closed: abort: No such file or directory: jdk/src/closed >> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >> jdk/make/closed: abort: No such file or directory: jdk/make/closed >> Waiting 5 secs before spawning next background command. >> .... >> >> >> -Chris. From kelly.ohair at oracle.com Mon Feb 4 22:20:37 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 4 Feb 2013 14:20:37 -0800 Subject: This simple patch doubles the compile-speed of the hotspot repo on Windows In-Reply-To: References: <76DC1CA3-E0C7-4A2D-9E3D-4523C6A3D536@oracle.com> Message-ID: <1F65A118-150F-4CAD-B06E-99223F64FEB3@oracle.com> Got it. Thanks for this. -kto On Feb 4, 2013, at 1:04 AM, Fredrik ?hrstr?m wrote: > Issue filed, on its way in: > http://cr.openjdk.java.net/~ohrstrom/webrev-8007446-add-MP/ > > //Fredrik > > 2013/2/2 Kelly O'Hair : >> Great stuff. Have you filed an issue on this? Or shall I? >> >> >> -kto >> >> On Feb 1, 2013, at 4:58 AM, Fredrik ?hrstr?m wrote: >> >>> ie. use /MP on the cl.exe command line. >>> >>> On the build machine (Windows Server 2007, Visual Studio 2010, 32 HT >>> cores, 64GB ram) configuring with: >>> >>> sh configure --enable-sjavac >>> --with-freetype=/cygdrive/d/tools/freetype-amd64 >>> --with-boot-jdk=/cygdrive/d/java/jdk-7-fcs-bin-b147/ >>> >>> (You need to patch >>> src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java >>> line 256, change equals("windows)" to startswith("windows), this fix >>> is going into tl soon.) >>> >>> Without MP >>> ----- Build times ------- >>> Start 2013-02-01 12:23:50 >>> End 2013-02-01 12:35:20 >>> 00:00:32 corba >>> 00:04:43 hotspot >>> 00:00:15 jaxp >>> 00:00:24 jaxws >>> 00:04:49 jdk >>> 00:00:46 langtools >>> 00:11:30 TOTAL >>> ------------------------- >>> >>> With MP >>> ----- Build times ------- >>> Start 2013-02-01 12:54:54 >>> End 2013-02-01 13:03:56 >>> 00:00:31 corba >>> 00:02:20 hotspot >>> 00:00:14 jaxp >>> 00:00:22 jaxws >>> 00:04:44 jdk >>> 00:00:46 langtools >>> 00:09:02 TOTAL >>> ------------------------- >>> >>> For such a simple patch it is a nice speedup. Please test and see if >>> it improves the speed on your multi core machines. >>> >>> //Fredrik >>> >>> Oh, and for reference this is the speed without sjavac but with /MP. >>> >>> ----- Build times ------- >>> Start 2013-02-01 13:39:38 >>> End 2013-02-01 13:51:46 >>> 00:00:35 corba >>> 00:02:24 hotspot >>> 00:00:28 jaxp >>> 00:00:36 jaxws >>> 00:07:11 jdk >>> 00:00:48 langtools >>> 00:12:08 TOTAL >>> ------------------------- >>> >>> $ hg diff >>> diff -r 67498c863813 make/windows/makefiles/compile.make >>> --- a/make/windows/makefiles/compile.make Thu Jan 17 12:16:06 2013 +0100 >>> +++ b/make/windows/makefiles/compile.make Fri Feb 01 13:05:08 2013 +0100 >>> @@ -44,6 +44,7 @@ >>> # /GS Inserts security stack checks in some functions (VS2005 default) >>> # /Oi Use intrinsics (in /O2) >>> # /Od Disable all optimizations >>> +# /MP Use multiple cores for compilation >>> # >>> # NOTE: Normally following any of the above with a '-' will turn off that flag >>> # >>> @@ -52,7 +53,7 @@ >>> # improving the quality of crash log stack traces involving jvm.dll. >>> >>> # These are always used in all compiles >>> -CXX_FLAGS=/nologo /W3 /WX >>> +CXX_FLAGS=/nologo /W3 /WX /MP >>> >>> # Let's add debug information when Full Debug Symbols is enabled >>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>> diff -r 67498c863813 make/windows/makefiles/sa.make >>> --- a/make/windows/makefiles/sa.make Thu Jan 17 12:16:06 2013 +0100 >>> +++ b/make/windows/makefiles/sa.make Fri Feb 01 13:05:08 2013 +0100 >>> @@ -108,6 +108,8 @@ >>> SA_LFLAGS = $(SA_LFLAGS) -map -debug >>> !endif >>> >>> +SA_CFLAGS = $(SA_CFLAGS) -MP >>> + >>> # Note that we do not keep sawindbj.obj around as it would then >>> # get included in the dumpbin command in build_vm_def.sh >> From david.holmes at oracle.com Tue Feb 5 06:21:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Feb 2013 16:21:32 +1000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510BD3E6.1090103@oracle.com> References: <510BD3E6.1090103@oracle.com> Message-ID: <5110A4EC.1050907@oracle.com> Chris, When these failures occur does the failure get reflected in an error exit code? I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle JDK because the closed repos were skipped due to this bug :( David On 2/02/2013 12:40 AM, Chris Hegarty wrote: > [ to build-dev and core-libs-dev, expect reviewer from either, but will > integrate through jdk8/tl ] > > This issue is mainly of interest to Oracle engineers, but it effects the > public hgforest script. > > When hgforest.sh is run with an addition argument to specify a closed > server, there is a problem/race between the creation of the directories > to hold nested repositories and the clone itself. These directories need > to be created before the clone command is executed, otherwise it will > fail, as below. > > The trivial fix is to back off these nested repos until their containing > directory exists. > > Webrev: > http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ > > sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log > # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed > jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed > hotspot/test/closed deploy install sponsors pubs > > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > /java/devtools/sparc/mercurial/latest/bin/hg clone > http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed > jdk/src/closed: abort: No such file or directory: jdk/src/closed > jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > /java/devtools/sparc/mercurial/latest/bin/hg clone > http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed > jdk/make/closed: abort: No such file or directory: jdk/make/closed > Waiting 5 secs before spawning next background command. > .... > > > -Chris. From oehrstroem at gmail.com Tue Feb 5 06:38:04 2013 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Tue, 5 Feb 2013 07:38:04 +0100 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <5110A4EC.1050907@oracle.com> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> Message-ID: Fixing get_source.sh problem: We can hardcode pre-creation of the closed repo locations as mkdir -p calls. We can do the openjdk clone first (in parllell) and when that is finished do the closedjdk clone. We can drop parallell clone altogether because it does not give the speedup we are looking for? We could actually fix how the SCM handles the source code? (Yes, I know that I am reiterating my statement from 2011 here, but I find it incomprehensible that Java is stored in an SCM, in such a way that you cannot reliably bisect to a faulty commit, nor in fact extract any old code from the SCM, in a state that is guaranteed to work or even compile. Johan Walles and I developed a reasonably non-intrusive solution for this where get_source.sh is not needed. So, fixing get_source.sh is clearly in an uphill battle.) //Fredrik 2013/2/5 David Holmes : > Chris, > > When these failures occur does the failure get reflected in an error exit > code? > > I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle JDK > because the closed repos were skipped due to this bug :( > > David > > > On 2/02/2013 12:40 AM, Chris Hegarty wrote: >> >> [ to build-dev and core-libs-dev, expect reviewer from either, but will >> integrate through jdk8/tl ] >> >> This issue is mainly of interest to Oracle engineers, but it effects the >> public hgforest script. >> >> When hgforest.sh is run with an addition argument to specify a closed >> server, there is a problem/race between the creation of the directories >> to hold nested repositories and the clone itself. These directories need >> to be created before the clone command is executed, otherwise it will >> fail, as below. >> >> The trivial fix is to back off these nested repos until their containing >> directory exists. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >> >> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >> hotspot/test/closed deploy install sponsors pubs >> >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >> jdk/src/closed: abort: No such file or directory: jdk/src/closed >> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >> jdk/make/closed: abort: No such file or directory: jdk/make/closed >> Waiting 5 secs before spawning next background command. >> .... >> >> >> -Chris. From erik.joelsson at oracle.com Tue Feb 5 10:09:19 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 05 Feb 2013 11:09:19 +0100 Subject: Review Request: 8007524: build-infra: Incremental build of tools.jar broken Message-ID: <5110DA4F.9040204@oracle.com> The logic for setting up correct dependencies from class files to jar files in the macro SetupArchive is broken. This fixes two things. The wrong variable was used to filter files found and a ',' was missing in the macro call to CacheFind. Verifed that dependency list is now populated instead of empty as before, and that changing a class in javac caused tools.jar to be updated. http://cr.openjdk.java.net/~erikj/8007524/webrev.root.01/ /Erik From chris.hegarty at oracle.com Tue Feb 5 14:07:36 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 05 Feb 2013 14:07:36 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <5110A4EC.1050907@oracle.com> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> Message-ID: <51111228.5010707@oracle.com> On 02/05/2013 06:21 AM, David Holmes wrote: > Chris, > > When these failures occur does the failure get reflected in an error > exit code? Not currently, good point. > I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle JDK > because the closed repos were skipped due to this bug :( This is what I am seeing too, and the reason I proposed a patch to resolve it. Updated webrev; http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ 1) now checks, and returns, appropriate error code, so that higher level scripts can determine if it completed successfully 2) Added diagnostic error message to help identify potential future problems if a nested repo is blocked for too long -Chris. > > David > > On 2/02/2013 12:40 AM, Chris Hegarty wrote: >> [ to build-dev and core-libs-dev, expect reviewer from either, but will >> integrate through jdk8/tl ] >> >> This issue is mainly of interest to Oracle engineers, but it effects the >> public hgforest script. >> >> When hgforest.sh is run with an addition argument to specify a closed >> server, there is a problem/race between the creation of the directories >> to hold nested repositories and the clone itself. These directories need >> to be created before the clone command is executed, otherwise it will >> fail, as below. >> >> The trivial fix is to back off these nested repos until their containing >> directory exists. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >> >> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >> hotspot/test/closed deploy install sponsors pubs >> >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >> jdk/src/closed: abort: No such file or directory: jdk/src/closed >> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >> jdk/make/closed: abort: No such file or directory: jdk/make/closed >> Waiting 5 secs before spawning next background command. >> .... >> >> >> -Chris. From tim.bell at oracle.com Tue Feb 5 15:16:14 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 05 Feb 2013 07:16:14 -0800 Subject: Review Request: 8007524: build-infra: Incremental build of tools.jar broken In-Reply-To: <5110DA4F.9040204@oracle.com> References: <5110DA4F.9040204@oracle.com> Message-ID: <5111223E.9030705@oracle.com> Erik: > The logic for setting up correct dependencies from class files to jar > files in the macro SetupArchive is broken. This fixes two things. The > wrong variable was used to filter files found and a ',' was missing in > the macro call to CacheFind. Verifed that dependency list is now > populated instead of empty as before, and that changing a class in > javac caused tools.jar to be updated. > > http://cr.openjdk.java.net/~erikj/8007524/webrev.root.01/ Looks good. That was a very subtle fix. Tim From erik.joelsson at oracle.com Tue Feb 5 21:29:34 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 05 Feb 2013 21:29:34 +0000 Subject: hg: jdk8/build: 8007524: build-infra: Incremental build of tools.jar broken Message-ID: <20130205212934.5D41A4784D@hg.openjdk.java.net> Changeset: d3d9ab8ee7b0 Author: erikj Date: 2013-02-05 16:50 +0100 URL: http://hg.openjdk.java.net/jdk8/build/rev/d3d9ab8ee7b0 8007524: build-infra: Incremental build of tools.jar broken Reviewed-by: tbell ! common/makefiles/JavaCompilation.gmk From david.holmes at oracle.com Wed Feb 6 01:53:40 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Feb 2013 11:53:40 +1000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <51111228.5010707@oracle.com> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> <51111228.5010707@oracle.com> Message-ID: <5111B7A4.8040902@oracle.com> Hi Chris, I don't speak fluent sh but ... 204 # Terminate with exit 0 only if all subprocesses were successful 205 ec=0 206 if [ -d ${tmp} ]; then 207 for rc in `ls ${tmp}/*.pid.rc` ; do I don't think you need to subshell an invocation of ls, simply do for rc in "${tmp}/*.pid.rc" ; do 208 exit_code=`cat ${rc} | tr -d ' \n\r'` 209 if [ "${exit_code}" != "0" ] ; then 210 echo "WARNING: ${rc} exited abnormally." Not sure printing ${rc} will be very informative there ?? 211 ec=1 Is there a "break" we can add here? --- In get_source.sh # Get clones of all nested repositories ! sh ./common/bin/hgforest.sh clone "$@" || exit 1 # Update all existing repositories to the latest sources sh ./common/bin/hgforest.sh pull -u don't we want "|| exit 1" for the pull case as well? Thanks, David On 6/02/2013 12:07 AM, Chris Hegarty wrote: > On 02/05/2013 06:21 AM, David Holmes wrote: >> Chris, >> >> When these failures occur does the failure get reflected in an error >> exit code? > > Not currently, good point. > >> I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle JDK >> because the closed repos were skipped due to this bug :( > > This is what I am seeing too, and the reason I proposed a patch to > resolve it. > > Updated webrev; > http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ > > 1) now checks, and returns, appropriate error code, so that higher > level scripts can determine if it completed successfully > 2) Added diagnostic error message to help identify potential future > problems if a nested repo is blocked for too long > > -Chris. > >> >> David >> >> On 2/02/2013 12:40 AM, Chris Hegarty wrote: >>> [ to build-dev and core-libs-dev, expect reviewer from either, but will >>> integrate through jdk8/tl ] >>> >>> This issue is mainly of interest to Oracle engineers, but it effects the >>> public hgforest script. >>> >>> When hgforest.sh is run with an addition argument to specify a closed >>> server, there is a problem/race between the creation of the directories >>> to hold nested repositories and the clone itself. These directories need >>> to be created before the clone command is executed, otherwise it will >>> fail, as below. >>> >>> The trivial fix is to back off these nested repos until their containing >>> directory exists. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>> >>> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >>> hotspot/test/closed deploy install sponsors pubs >>> >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>> Waiting 5 secs before spawning next background command. >>> .... >>> >>> >>> -Chris. From david.katleman at oracle.com Wed Feb 6 03:14:51 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 06 Feb 2013 03:14:51 +0000 Subject: hg: jdk8/build: 2 new changesets Message-ID: <20130206031452.1BC4447865@hg.openjdk.java.net> Changeset: 5b19cef637a6 Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/5b19cef637a6 Added tag jdk8-b75 for changeset 2a713921952c ! .hgtags Changeset: 278af9fc67e7 Author: katleman Date: 2013-02-05 18:54 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/278af9fc67e7 Merge From david.katleman at oracle.com Wed Feb 6 03:14:57 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 06 Feb 2013 03:14:57 +0000 Subject: hg: jdk8/build/corba: 2 new changesets Message-ID: <20130206031459.6531847866@hg.openjdk.java.net> Changeset: 4a6be02e66a3 Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/4a6be02e66a3 Added tag jdk8-b75 for changeset d4e68ce17795 ! .hgtags Changeset: 58be6ca3c060 Author: katleman Date: 2013-02-05 18:54 -0800 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/58be6ca3c060 Merge From david.katleman at oracle.com Wed Feb 6 03:16:19 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 06 Feb 2013 03:16:19 +0000 Subject: hg: jdk8/build/hotspot: Added tag jdk8-b75 for changeset 6778d0b16593 Message-ID: <20130206031623.26E7947867@hg.openjdk.java.net> Changeset: 20b605466ccb Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/20b605466ccb Added tag jdk8-b75 for changeset 6778d0b16593 ! .hgtags From david.katleman at oracle.com Wed Feb 6 03:17:30 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 06 Feb 2013 03:17:30 +0000 Subject: hg: jdk8/build/jaxp: 2 new changesets Message-ID: <20130206031737.5008D47868@hg.openjdk.java.net> Changeset: 8d65b381880b Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/8d65b381880b Added tag jdk8-b75 for changeset ff0b73a6b3f6 ! .hgtags Changeset: 0c08593944d0 Author: katleman Date: 2013-02-05 18:54 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/0c08593944d0 Merge From david.katleman at oracle.com Wed Feb 6 03:17:42 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 06 Feb 2013 03:17:42 +0000 Subject: hg: jdk8/build/jaxws: 2 new changesets Message-ID: <20130206031747.68E3447869@hg.openjdk.java.net> Changeset: a63ef2391c20 Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/a63ef2391c20 Added tag jdk8-b75 for changeset 966bf9f3c41a ! .hgtags Changeset: c4853f3f0e89 Author: katleman Date: 2013-02-05 18:54 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/c4853f3f0e89 Merge From david.katleman at oracle.com Wed Feb 6 03:17:56 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 06 Feb 2013 03:17:56 +0000 Subject: hg: jdk8/build/jdk: 2 new changesets Message-ID: <20130206031830.56B3A4786A@hg.openjdk.java.net> Changeset: 6ba6353ab42c Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6ba6353ab42c Added tag jdk8-b75 for changeset 4a67fdb752b7 ! .hgtags Changeset: 3a2630528661 Author: katleman Date: 2013-02-05 18:54 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3a2630528661 Merge From david.katleman at oracle.com Wed Feb 6 03:19:44 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 06 Feb 2013 03:19:44 +0000 Subject: hg: jdk8/build/langtools: 2 new changesets Message-ID: <20130206031951.581964786B@hg.openjdk.java.net> Changeset: 716935fec613 Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/716935fec613 Added tag jdk8-b75 for changeset c2e11e2ec4a3 ! .hgtags Changeset: e81839b32337 Author: katleman Date: 2013-02-05 18:55 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/e81839b32337 Merge From chris.hegarty at oracle.com Wed Feb 6 10:04:56 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 06 Feb 2013 10:04:56 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <5111B7A4.8040902@oracle.com> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> <51111228.5010707@oracle.com> <5111B7A4.8040902@oracle.com> Message-ID: <51122AC8.2070400@oracle.com> Thank for the review. comments inline... On 06/02/2013 01:53, David Holmes wrote: > 204 # Terminate with exit 0 only if all subprocesses were successful > 205 ec=0 > 206 if [ -d ${tmp} ]; then > 207 for rc in `ls ${tmp}/*.pid.rc` ; do > > I don't think you need to subshell an invocation of ls, simply do > > for rc in "${tmp}/*.pid.rc" ; do Yes this is better, but the quotes are incorrect. It should simply be for rc in ${tmp}/*.pid.rc ; do > 208 exit_code=`cat ${rc} | tr -d ' \n\r'` > 209 if [ "${exit_code}" != "0" ] ; then > 210 echo "WARNING: ${rc} exited abnormally." > > Not sure printing ${rc} will be very informative there ?? It prints the file name which contains the subrepo name. Not pretty, but this gives more information about which clone/pull failed. > 211 ec=1 > > Is there a "break" we can add here? Yes, we could break out/exit early, but I deliberately want to iterator over all the child process exits codes to better highlight which ones, if more than one, failed. > In get_source.sh > > # Get clones of all nested repositories > ! sh ./common/bin/hgforest.sh clone "$@" || exit 1 > > # Update all existing repositories to the latest sources > sh ./common/bin/hgforest.sh pull -u > > don't we want "|| exit 1" for the pull case as well? Since the pull is the last command there is no need for "|| exit 1", since its exit code will be returned. -Chris. > > Thanks, > David > > On 6/02/2013 12:07 AM, Chris Hegarty wrote: >> On 02/05/2013 06:21 AM, David Holmes wrote: >>> Chris, >>> >>> When these failures occur does the failure get reflected in an error >>> exit code? >> >> Not currently, good point. >> >>> I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle JDK >>> because the closed repos were skipped due to this bug :( >> >> This is what I am seeing too, and the reason I proposed a patch to >> resolve it. >> >> Updated webrev; >> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >> >> 1) now checks, and returns, appropriate error code, so that higher >> level scripts can determine if it completed successfully >> 2) Added diagnostic error message to help identify potential future >> problems if a nested repo is blocked for too long >> >> -Chris. >> >>> >>> David >>> >>> On 2/02/2013 12:40 AM, Chris Hegarty wrote: >>>> [ to build-dev and core-libs-dev, expect reviewer from either, but will >>>> integrate through jdk8/tl ] >>>> >>>> This issue is mainly of interest to Oracle engineers, but it effects >>>> the >>>> public hgforest script. >>>> >>>> When hgforest.sh is run with an addition argument to specify a closed >>>> server, there is a problem/race between the creation of the directories >>>> to hold nested repositories and the clone itself. These directories >>>> need >>>> to be created before the clone command is executed, otherwise it will >>>> fail, as below. >>>> >>>> The trivial fix is to back off these nested repos until their >>>> containing >>>> directory exists. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>>> >>>> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >>>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>>> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >>>> hotspot/test/closed deploy install sponsors pubs >>>> >>>> Waiting 5 secs before spawning next background command. >>>> Waiting 5 secs before spawning next background command. >>>> Waiting 5 secs before spawning next background command. >>>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>>> Waiting 5 secs before spawning next background command. >>>> .... >>>> >>>> >>>> -Chris. From david.holmes at oracle.com Wed Feb 6 10:24:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Feb 2013 20:24:52 +1000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <51122AC8.2070400@oracle.com> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> <51111228.5010707@oracle.com> <5111B7A4.8040902@oracle.com> <51122AC8.2070400@oracle.com> Message-ID: <51122F74.4000301@oracle.com> Thanks Chris. I missed a couple of obvious things there. :( One thing related to the repo name in the $(rc) variable. Somewhere the repo name gets mangled: + echo jdk/src/closed + sed -e s at ./@@ -e s@/@_ at g + repopidfile=jdsrc_closed the / to _ doesn't work for the first / (not part of your fix though). I must say though that this bug still has me perplexed. I ran with set -x and observed the following. Given: # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs The first clone I see is corba and the second is jdk/make/closed. The very last clone I see is jdk. BUT there was no error creating the sub-repos before the enclosing repo! ??? Makes no sense. David ----- On 6/02/2013 8:04 PM, Chris Hegarty wrote: > Thank for the review. comments inline... > > On 06/02/2013 01:53, David Holmes wrote: >> 204 # Terminate with exit 0 only if all subprocesses were successful >> 205 ec=0 >> 206 if [ -d ${tmp} ]; then >> 207 for rc in `ls ${tmp}/*.pid.rc` ; do >> >> I don't think you need to subshell an invocation of ls, simply do >> >> for rc in "${tmp}/*.pid.rc" ; do > > Yes this is better, but the quotes are incorrect. It should simply be > for rc in ${tmp}/*.pid.rc ; do > >> 208 exit_code=`cat ${rc} | tr -d ' \n\r'` >> 209 if [ "${exit_code}" != "0" ] ; then >> 210 echo "WARNING: ${rc} exited abnormally." >> >> Not sure printing ${rc} will be very informative there ?? > > It prints the file name which contains the subrepo name. Not pretty, but > this gives more information about which clone/pull failed. > >> 211 ec=1 >> >> Is there a "break" we can add here? > > Yes, we could break out/exit early, but I deliberately want to iterator > over all the child process exits codes to better highlight which ones, > if more than one, failed. > >> In get_source.sh >> >> # Get clones of all nested repositories >> ! sh ./common/bin/hgforest.sh clone "$@" || exit 1 >> >> # Update all existing repositories to the latest sources >> sh ./common/bin/hgforest.sh pull -u >> >> don't we want "|| exit 1" for the pull case as well? > > Since the pull is the last command there is no need for "|| exit 1", > since its exit code will be returned. > > -Chris. > >> >> Thanks, >> David >> >> On 6/02/2013 12:07 AM, Chris Hegarty wrote: >>> On 02/05/2013 06:21 AM, David Holmes wrote: >>>> Chris, >>>> >>>> When these failures occur does the failure get reflected in an error >>>> exit code? >>> >>> Not currently, good point. >>> >>>> I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle JDK >>>> because the closed repos were skipped due to this bug :( >>> >>> This is what I am seeing too, and the reason I proposed a patch to >>> resolve it. >>> >>> Updated webrev; >>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>> >>> 1) now checks, and returns, appropriate error code, so that higher >>> level scripts can determine if it completed successfully >>> 2) Added diagnostic error message to help identify potential future >>> problems if a nested repo is blocked for too long >>> >>> -Chris. >>> >>>> >>>> David >>>> >>>> On 2/02/2013 12:40 AM, Chris Hegarty wrote: >>>>> [ to build-dev and core-libs-dev, expect reviewer from either, but >>>>> will >>>>> integrate through jdk8/tl ] >>>>> >>>>> This issue is mainly of interest to Oracle engineers, but it effects >>>>> the >>>>> public hgforest script. >>>>> >>>>> When hgforest.sh is run with an addition argument to specify a closed >>>>> server, there is a problem/race between the creation of the >>>>> directories >>>>> to hold nested repositories and the clone itself. These directories >>>>> need >>>>> to be created before the clone command is executed, otherwise it will >>>>> fail, as below. >>>>> >>>>> The trivial fix is to back off these nested repos until their >>>>> containing >>>>> directory exists. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>>>> >>>>> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >>>>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>>>> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >>>>> hotspot/test/closed deploy install sponsors pubs >>>>> >>>>> Waiting 5 secs before spawning next background command. >>>>> Waiting 5 secs before spawning next background command. >>>>> Waiting 5 secs before spawning next background command. >>>>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>>>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>>>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>>>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>>>> Waiting 5 secs before spawning next background command. >>>>> .... >>>>> >>>>> >>>>> -Chris. From chris.hegarty at oracle.com Wed Feb 6 10:41:39 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 06 Feb 2013 10:41:39 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <51122F74.4000301@oracle.com> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> <51111228.5010707@oracle.com> <5111B7A4.8040902@oracle.com> <51122AC8.2070400@oracle.com> <51122F74.4000301@oracle.com> Message-ID: <51123363.8080606@oracle.com> On 06/02/2013 10:24, David Holmes wrote: > Thanks Chris. I missed a couple of obvious things there. :( > > One thing related to the repo name in the $(rc) variable. Somewhere the > repo name gets mangled: > > + echo jdk/src/closed > + sed -e s at ./@@ -e s@/@_ at g > + repopidfile=jdsrc_closed > > the / to _ doesn't work for the first / (not part of your fix though). > > I must say though that this bug still has me perplexed. I ran with set > -x and observed the following. Given: > > # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed > jdk/make/closed jdk/test/closed hotspot/make/closed > hotspot/src/closed hotspot/test/closed deploy install sponsors pubs > > The first clone I see is corba and the second is jdk/make/closed. The > very last clone I see is jdk. BUT there was no error creating the > sub-repos before the enclosing repo! ??? Makes no sense. I only see the problem when running with old versions of hg. More recent ones seem to be immune to it. I guess they must do something equivalent to 'mkdir -p' on the destination directory. Blocking the clone of the nested repos until the enclosing repo creates the holding directory seems like a small price to pay for such an obscure bug. Also, now returning an error code when something fails should help avoid any future issues of missing or out of date repos. -Chris. > > David > ----- > > On 6/02/2013 8:04 PM, Chris Hegarty wrote: >> Thank for the review. comments inline... >> >> On 06/02/2013 01:53, David Holmes wrote: >>> 204 # Terminate with exit 0 only if all subprocesses were successful >>> 205 ec=0 >>> 206 if [ -d ${tmp} ]; then >>> 207 for rc in `ls ${tmp}/*.pid.rc` ; do >>> >>> I don't think you need to subshell an invocation of ls, simply do >>> >>> for rc in "${tmp}/*.pid.rc" ; do >> >> Yes this is better, but the quotes are incorrect. It should simply be >> for rc in ${tmp}/*.pid.rc ; do >> >>> 208 exit_code=`cat ${rc} | tr -d ' \n\r'` >>> 209 if [ "${exit_code}" != "0" ] ; then >>> 210 echo "WARNING: ${rc} exited abnormally." >>> >>> Not sure printing ${rc} will be very informative there ?? >> >> It prints the file name which contains the subrepo name. Not pretty, but >> this gives more information about which clone/pull failed. >> >>> 211 ec=1 >>> >>> Is there a "break" we can add here? >> >> Yes, we could break out/exit early, but I deliberately want to iterator >> over all the child process exits codes to better highlight which ones, >> if more than one, failed. >> >>> In get_source.sh >>> >>> # Get clones of all nested repositories >>> ! sh ./common/bin/hgforest.sh clone "$@" || exit 1 >>> >>> # Update all existing repositories to the latest sources >>> sh ./common/bin/hgforest.sh pull -u >>> >>> don't we want "|| exit 1" for the pull case as well? >> >> Since the pull is the last command there is no need for "|| exit 1", >> since its exit code will be returned. >> >> -Chris. >> >>> >>> Thanks, >>> David >>> >>> On 6/02/2013 12:07 AM, Chris Hegarty wrote: >>>> On 02/05/2013 06:21 AM, David Holmes wrote: >>>>> Chris, >>>>> >>>>> When these failures occur does the failure get reflected in an error >>>>> exit code? >>>> >>>> Not currently, good point. >>>> >>>>> I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle >>>>> JDK >>>>> because the closed repos were skipped due to this bug :( >>>> >>>> This is what I am seeing too, and the reason I proposed a patch to >>>> resolve it. >>>> >>>> Updated webrev; >>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>>> >>>> 1) now checks, and returns, appropriate error code, so that higher >>>> level scripts can determine if it completed successfully >>>> 2) Added diagnostic error message to help identify potential future >>>> problems if a nested repo is blocked for too long >>>> >>>> -Chris. >>>> >>>>> >>>>> David >>>>> >>>>> On 2/02/2013 12:40 AM, Chris Hegarty wrote: >>>>>> [ to build-dev and core-libs-dev, expect reviewer from either, but >>>>>> will >>>>>> integrate through jdk8/tl ] >>>>>> >>>>>> This issue is mainly of interest to Oracle engineers, but it effects >>>>>> the >>>>>> public hgforest script. >>>>>> >>>>>> When hgforest.sh is run with an addition argument to specify a closed >>>>>> server, there is a problem/race between the creation of the >>>>>> directories >>>>>> to hold nested repositories and the clone itself. These directories >>>>>> need >>>>>> to be created before the clone command is executed, otherwise it will >>>>>> fail, as below. >>>>>> >>>>>> The trivial fix is to back off these nested repos until their >>>>>> containing >>>>>> directory exists. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>>>>> >>>>>> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >>>>>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>>>>> jdk/make/closed jdk/test/closed hotspot/make/closed >>>>>> hotspot/src/closed >>>>>> hotspot/test/closed deploy install sponsors pubs >>>>>> >>>>>> Waiting 5 secs before spawning next background command. >>>>>> Waiting 5 secs before spawning next background command. >>>>>> Waiting 5 secs before spawning next background command. >>>>>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>>>>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>>>>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>>>>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>>>>> Waiting 5 secs before spawning next background command. >>>>>> .... >>>>>> >>>>>> >>>>>> -Chris. From neil.richards at ngmr.net Wed Feb 6 16:51:15 2013 From: neil.richards at ngmr.net (Neil Richards) Date: Wed, 06 Feb 2013 16:51:15 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <51123363.8080606@oracle.com> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> <51111228.5010707@oracle.com> <5111B7A4.8040902@oracle.com> <51122AC8.2070400@oracle.com> <51122F74.4000301@oracle.com> <51123363.8080606@oracle.com> Message-ID: <1360169475.24601.185.camel@chalkhill> fwiw, I've always found the attempts by hg_forest to process things in parallel cause me more pain than it's worth. Marching through the repo locations serially in order might take a few moments longer elapsed time, but creates instantly understandable status / output / log and points for returning sensible errors when things don't succeed. Doing so also reduces the burst load on the server (it has to deal with one request per invocation at any time, rather than five? (or more)), which also strikes me as a win. (There are times that my 'hg pull' requests get momentarily rebuffed by the OpenJDK server, in a manner that suggests to me it's getting flooded by such requests). Obviously, figuring out how to do everything properly in parallel is a lot more fun :) ... but I don't think this script is there yet, and I wonder if the KISS principle shouldn't apply here. Regards, Neil On Wed, 2013-02-06 at 10:41 +0000, Chris Hegarty wrote: > > On 06/02/2013 10:24, David Holmes wrote: > > Thanks Chris. I missed a couple of obvious things there. :( > > > > One thing related to the repo name in the $(rc) variable. Somewhere the > > repo name gets mangled: > > > > + echo jdk/src/closed > > + sed -e s at ./@@ -e s@/@_ at g > > + repopidfile=jdsrc_closed > > > > the / to _ doesn't work for the first / (not part of your fix though). > > > > I must say though that this bug still has me perplexed. I ran with set > > -x and observed the following. Given: > > > > # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed > > jdk/make/closed jdk/test/closed hotspot/make/closed > > hotspot/src/closed hotspot/test/closed deploy install sponsors pubs > > > > The first clone I see is corba and the second is jdk/make/closed. The > > very last clone I see is jdk. BUT there was no error creating the > > sub-repos before the enclosing repo! ??? Makes no sense. > > I only see the problem when running with old versions of hg. More recent > ones seem to be immune to it. I guess they must do something equivalent > to 'mkdir -p' on the destination directory. > > Blocking the clone of the nested repos until the enclosing repo creates > the holding directory seems like a small price to pay for such an > obscure bug. > > Also, now returning an error code when something fails should help avoid > any future issues of missing or out of date repos. > > -Chris. > > > > > David > > ----- > > > > On 6/02/2013 8:04 PM, Chris Hegarty wrote: > >> Thank for the review. comments inline... > >> > >> On 06/02/2013 01:53, David Holmes wrote: > >>> 204 # Terminate with exit 0 only if all subprocesses were successful > >>> 205 ec=0 > >>> 206 if [ -d ${tmp} ]; then > >>> 207 for rc in `ls ${tmp}/*.pid.rc` ; do > >>> > >>> I don't think you need to subshell an invocation of ls, simply do > >>> > >>> for rc in "${tmp}/*.pid.rc" ; do > >> > >> Yes this is better, but the quotes are incorrect. It should simply be > >> for rc in ${tmp}/*.pid.rc ; do > >> > >>> 208 exit_code=`cat ${rc} | tr -d ' \n\r'` > >>> 209 if [ "${exit_code}" != "0" ] ; then > >>> 210 echo "WARNING: ${rc} exited abnormally." > >>> > >>> Not sure printing ${rc} will be very informative there ?? > >> > >> It prints the file name which contains the subrepo name. Not pretty, but > >> this gives more information about which clone/pull failed. > >> > >>> 211 ec=1 > >>> > >>> Is there a "break" we can add here? > >> > >> Yes, we could break out/exit early, but I deliberately want to iterator > >> over all the child process exits codes to better highlight which ones, > >> if more than one, failed. > >> > >>> In get_source.sh > >>> > >>> # Get clones of all nested repositories > >>> ! sh ./common/bin/hgforest.sh clone "$@" || exit 1 > >>> > >>> # Update all existing repositories to the latest sources > >>> sh ./common/bin/hgforest.sh pull -u > >>> > >>> don't we want "|| exit 1" for the pull case as well? > >> > >> Since the pull is the last command there is no need for "|| exit 1", > >> since its exit code will be returned. > >> > >> -Chris. > >> > >>> > >>> Thanks, > >>> David > >>> > >>> On 6/02/2013 12:07 AM, Chris Hegarty wrote: > >>>> On 02/05/2013 06:21 AM, David Holmes wrote: > >>>>> Chris, > >>>>> > >>>>> When these failures occur does the failure get reflected in an error > >>>>> exit code? > >>>> > >>>> Not currently, good point. > >>>> > >>>>> I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle > >>>>> JDK > >>>>> because the closed repos were skipped due to this bug :( > >>>> > >>>> This is what I am seeing too, and the reason I proposed a patch to > >>>> resolve it. > >>>> > >>>> Updated webrev; > >>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ > >>>> > >>>> 1) now checks, and returns, appropriate error code, so that higher > >>>> level scripts can determine if it completed successfully > >>>> 2) Added diagnostic error message to help identify potential future > >>>> problems if a nested repo is blocked for too long > >>>> > >>>> -Chris. > >>>> > >>>>> > >>>>> David > >>>>> > >>>>> On 2/02/2013 12:40 AM, Chris Hegarty wrote: > >>>>>> [ to build-dev and core-libs-dev, expect reviewer from either, but > >>>>>> will > >>>>>> integrate through jdk8/tl ] > >>>>>> > >>>>>> This issue is mainly of interest to Oracle engineers, but it effects > >>>>>> the > >>>>>> public hgforest script. > >>>>>> > >>>>>> When hgforest.sh is run with an addition argument to specify a closed > >>>>>> server, there is a problem/race between the creation of the > >>>>>> directories > >>>>>> to hold nested repositories and the clone itself. These directories > >>>>>> need > >>>>>> to be created before the clone command is executed, otherwise it will > >>>>>> fail, as below. > >>>>>> > >>>>>> The trivial fix is to back off these nested repos until their > >>>>>> containing > >>>>>> directory exists. > >>>>>> > >>>>>> Webrev: > >>>>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ > >>>>>> > >>>>>> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log > >>>>>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed > >>>>>> jdk/make/closed jdk/test/closed hotspot/make/closed > >>>>>> hotspot/src/closed > >>>>>> hotspot/test/closed deploy install sponsors pubs > >>>>>> > >>>>>> Waiting 5 secs before spawning next background command. > >>>>>> Waiting 5 secs before spawning next background command. > >>>>>> Waiting 5 secs before spawning next background command. > >>>>>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > >>>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone > >>>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed > >>>>>> jdk/src/closed: abort: No such file or directory: jdk/src/closed > >>>>>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > >>>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone > >>>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed > >>>>>> jdk/make/closed: abort: No such file or directory: jdk/make/closed > >>>>>> Waiting 5 secs before spawning next background command. > >>>>>> .... > >>>>>> > >>>>>> > >>>>>> -Chris. -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From chris.hegarty at oracle.com Wed Feb 6 17:03:36 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 06 Feb 2013 17:03:36 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <1360169475.24601.185.camel@chalkhill> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> <51111228.5010707@oracle.com> <5111B7A4.8040902@oracle.com> <51122AC8.2070400@oracle.com> <51122F74.4000301@oracle.com> <51123363.8080606@oracle.com> <1360169475.24601.185.camel@chalkhill> Message-ID: <51128CE8.7090606@oracle.com> Neil, I think a wider discussion needs to be had around how this script should operate, but I didn't want this specific issue to get side tracked by that. The hgforest script already clones/pulls in parallel, the problem here is that it just doesn't work with older versions of hg. And worse than that doesn't even return an error. I simply want to resolve this issue so that the script is once again useable. If there is an issue with parallel clones/pulls, then we should consider that separately. -Chris. On 06/02/2013 16:51, Neil Richards wrote: > fwiw, I've always found the attempts by hg_forest to process things in > parallel cause me more pain than it's worth. > > Marching through the repo locations serially in order might take a few > moments longer elapsed time, but creates instantly understandable > status / output / log and points for returning sensible errors when > things don't succeed. > > Doing so also reduces the burst load on the server (it has to deal with > one request per invocation at any time, rather than five? (or more)), > which also strikes me as a win. > > (There are times that my 'hg pull' requests get momentarily rebuffed by > the OpenJDK server, in a manner that suggests to me it's getting flooded > by such requests). > > Obviously, figuring out how to do everything properly in parallel is a > lot more fun :) ... > but I don't think this script is there yet, and I wonder if the KISS > principle shouldn't apply here. > > Regards, > Neil > > On Wed, 2013-02-06 at 10:41 +0000, Chris Hegarty wrote: >> >> On 06/02/2013 10:24, David Holmes wrote: >>> Thanks Chris. I missed a couple of obvious things there. :( >>> >>> One thing related to the repo name in the $(rc) variable. Somewhere the >>> repo name gets mangled: >>> >>> + echo jdk/src/closed >>> + sed -e s at ./@@ -e s@/@_ at g >>> + repopidfile=jdsrc_closed >>> >>> the / to _ doesn't work for the first / (not part of your fix though). >>> >>> I must say though that this bug still has me perplexed. I ran with set >>> -x and observed the following. Given: >>> >>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>> jdk/make/closed jdk/test/closed hotspot/make/closed >>> hotspot/src/closed hotspot/test/closed deploy install sponsors pubs >>> >>> The first clone I see is corba and the second is jdk/make/closed. The >>> very last clone I see is jdk. BUT there was no error creating the >>> sub-repos before the enclosing repo! ??? Makes no sense. >> >> I only see the problem when running with old versions of hg. More recent >> ones seem to be immune to it. I guess they must do something equivalent >> to 'mkdir -p' on the destination directory. >> >> Blocking the clone of the nested repos until the enclosing repo creates >> the holding directory seems like a small price to pay for such an >> obscure bug. >> >> Also, now returning an error code when something fails should help avoid >> any future issues of missing or out of date repos. >> >> -Chris. >> >>> >>> David >>> ----- >>> >>> On 6/02/2013 8:04 PM, Chris Hegarty wrote: >>>> Thank for the review. comments inline... >>>> >>>> On 06/02/2013 01:53, David Holmes wrote: >>>>> 204 # Terminate with exit 0 only if all subprocesses were successful >>>>> 205 ec=0 >>>>> 206 if [ -d ${tmp} ]; then >>>>> 207 for rc in `ls ${tmp}/*.pid.rc` ; do >>>>> >>>>> I don't think you need to subshell an invocation of ls, simply do >>>>> >>>>> for rc in "${tmp}/*.pid.rc" ; do >>>> >>>> Yes this is better, but the quotes are incorrect. It should simply be >>>> for rc in ${tmp}/*.pid.rc ; do >>>> >>>>> 208 exit_code=`cat ${rc} | tr -d ' \n\r'` >>>>> 209 if [ "${exit_code}" != "0" ] ; then >>>>> 210 echo "WARNING: ${rc} exited abnormally." >>>>> >>>>> Not sure printing ${rc} will be very informative there ?? >>>> >>>> It prints the file name which contains the subrepo name. Not pretty, but >>>> this gives more information about which clone/pull failed. >>>> >>>>> 211 ec=1 >>>>> >>>>> Is there a "break" we can add here? >>>> >>>> Yes, we could break out/exit early, but I deliberately want to iterator >>>> over all the child process exits codes to better highlight which ones, >>>> if more than one, failed. >>>> >>>>> In get_source.sh >>>>> >>>>> # Get clones of all nested repositories >>>>> ! sh ./common/bin/hgforest.sh clone "$@" || exit 1 >>>>> >>>>> # Update all existing repositories to the latest sources >>>>> sh ./common/bin/hgforest.sh pull -u >>>>> >>>>> don't we want "|| exit 1" for the pull case as well? >>>> >>>> Since the pull is the last command there is no need for "|| exit 1", >>>> since its exit code will be returned. >>>> >>>> -Chris. >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 6/02/2013 12:07 AM, Chris Hegarty wrote: >>>>>> On 02/05/2013 06:21 AM, David Holmes wrote: >>>>>>> Chris, >>>>>>> >>>>>>> When these failures occur does the failure get reflected in an error >>>>>>> exit code? >>>>>> >>>>>> Not currently, good point. >>>>>> >>>>>>> I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle >>>>>>> JDK >>>>>>> because the closed repos were skipped due to this bug :( >>>>>> >>>>>> This is what I am seeing too, and the reason I proposed a patch to >>>>>> resolve it. >>>>>> >>>>>> Updated webrev; >>>>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>>>>> >>>>>> 1) now checks, and returns, appropriate error code, so that higher >>>>>> level scripts can determine if it completed successfully >>>>>> 2) Added diagnostic error message to help identify potential future >>>>>> problems if a nested repo is blocked for too long >>>>>> >>>>>> -Chris. >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 2/02/2013 12:40 AM, Chris Hegarty wrote: >>>>>>>> [ to build-dev and core-libs-dev, expect reviewer from either, but >>>>>>>> will >>>>>>>> integrate through jdk8/tl ] >>>>>>>> >>>>>>>> This issue is mainly of interest to Oracle engineers, but it effects >>>>>>>> the >>>>>>>> public hgforest script. >>>>>>>> >>>>>>>> When hgforest.sh is run with an addition argument to specify a closed >>>>>>>> server, there is a problem/race between the creation of the >>>>>>>> directories >>>>>>>> to hold nested repositories and the clone itself. These directories >>>>>>>> need >>>>>>>> to be created before the clone command is executed, otherwise it will >>>>>>>> fail, as below. >>>>>>>> >>>>>>>> The trivial fix is to back off these nested repos until their >>>>>>>> containing >>>>>>>> directory exists. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>>>>>>> >>>>>>>> sh ./get_source.sh http://xxx.yyy.oracle.com |& tee clone.log >>>>>>>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>>>>>>> jdk/make/closed jdk/test/closed hotspot/make/closed >>>>>>>> hotspot/src/closed >>>>>>>> hotspot/test/closed deploy install sponsors pubs >>>>>>>> >>>>>>>> Waiting 5 secs before spawning next background command. >>>>>>>> Waiting 5 secs before spawning next background command. >>>>>>>> Waiting 5 secs before spawning next background command. >>>>>>>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>>>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>>>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>>>>>>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>>>>>>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>>>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>>>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>>>>>>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>>>>>>> Waiting 5 secs before spawning next background command. >>>>>>>> .... >>>>>>>> >>>>>>>> >>>>>>>> -Chris. > > From chris.hegarty at oracle.com Wed Feb 6 17:59:00 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 6 Feb 2013 17:59:00 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <20130206162627.4080E97129@rebar.astron.com> References: <20130206162627.4080E97129@rebar.astron.com> Message-ID: <87AF0D9E-8DEB-4CC0-84F3-83B83A1774DD@oracle.com> On 6 Feb 2013, at 16:26, christos at zoulas.com wrote: > On Feb 6, 10:04am, chris.hegarty at oracle.com (Chris Hegarty) wrote: > -- Subject: Re: RFR: race with nested repos in hgforest.sh > > | Yes this is better, but the quotes are incorrect. It should simply be > | for rc in ${tmp}/*.pid.rc ; do > > This will break if there is no match. This should never happen, but I agree the code could be more robust. -Chris > > christos From jonathan.gibbons at oracle.com Thu Feb 7 03:17:38 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 06 Feb 2013 19:17:38 -0800 Subject: typo Message-ID: <51131CD2.3060005@oracle.com> common/makefiles/JavaCompilation.gmk line 162 dechipher. -- Jon From jonathan.gibbons at oracle.com Thu Feb 7 03:19:46 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 06 Feb 2013 19:19:46 -0800 Subject: typo In-Reply-To: <51131CD2.3060005@oracle.com> References: <51131CD2.3060005@oracle.com> Message-ID: <51131D52.9050709@oracle.com> On 02/06/2013 07:17 PM, Jonathan Gibbons wrote: > common/makefiles/JavaCompilation.gmk > > line 162 > dechipher. > > -- Jon line 518 buliding From rnielsen at vocera.com Thu Feb 7 07:59:17 2013 From: rnielsen at vocera.com (Randy Nielsen) Date: Wed, 6 Feb 2013 23:59:17 -0800 Subject: Hang building JDK 7 Hotspot in Windows 7 Message-ID: <1AC3281AD57A34468B9879C754022CAF05F1497130@exchange.vocera.local> I am thoroughly stuck building JDK 7 when I start the Hotspot portion of the build. This is Windows 7 64 bit building 64 bit JDK with Visual Studio 10 Service Pack 1. The hang seems to happen immediately after I start the hotspot portion of the make. There is no output at all. Watching the Windows Task Manager in the Processes tab shows the System Idle process at 99% almost all of the time. Occasionally mscorsvw.exe (.NET services) or minty.exe gets a few % of CPU but only very briefly. >From browsing the web I've tried the following "fixes": verified that there was no anti-virus program, and disabled ASLR (Address Space Layout Randomization). No change in behavior. Has anyone any ideas about how to deal with this? Also are there settings in the make that will dramatically increase the level of logging in the make that might help me debug this? Here's the output of the make hotspot: /usr/bin/mkdir -p C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir /usr/bin/mkdir -p C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import ######################################################################## ######################################################################## ##### Entering hotspot for target(s) all_product ##### ######################################################################## cd ./hotspot/make && \ make JDK_TOPDIR=C:/OpenJDK/openjdk/jdk JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir ALT_EXPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import ALT_SLASH_JAVA="c:/OpenJDK" ALT_BOOTDIR=c:/OpenJDK/jdk-6u18 ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist all_product ==>> That's it - no more output. The output of the sanity portion of the make is below. Hoping someone can help! Randy $ make cygwin warning: MS-DOS style path detected: C:/Windows/system32/wscript.exe Preferred POSIX equivalent is: /cygdrive/c/Windows/system32/wscript.exe CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames ( cd ./jdk/make && \ make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=C:/OpenJDK/openjdk/jdk JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64 ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist ALT_CORBA_DIST=C:/OpenJDK/openjdk/build/windows-amd64/corba/dist ALT_JAXP_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist ALT_JAXWS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist ALT_HOTSPOT_IMPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import BUILD_HOTSPOT=true ; ) make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' make[1]: Leaving directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' Build Machine Information: build machine = WIN-R7HSHTAIIHC Build Directory Structure: CWD = /cygdrive/c/OpenJDK/openjdk TOPDIR = . LANGTOOLS_TOPDIR = ./langtools JAXP_TOPDIR = ./jaxp JAXWS_TOPDIR = ./jaxws CORBA_TOPDIR = ./corba HOTSPOT_TOPDIR = ./hotspot JDK_TOPDIR = ./jdk Build Directives: BUILD_LANGTOOLS = true BUILD_JAXP = true BUILD_JAXWS = true BUILD_CORBA = true BUILD_HOTSPOT = true BUILD_JDK = true DEBUG_CLASSFILES = DEBUG_BINARIES = Hotspot Settings: HOTSPOT_BUILD_JOBS = HOTSPOT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir HOTSPOT_EXPORT_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import Bootstrap Settings: BOOTDIR = c:/OpenJDK/jdk-6u18 ALT_BOOTDIR = c:/OpenJDK/jdk-6u18 BOOT_VER = 1.6.0 [requires at least 1.6] OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 ALT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 ABS_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 Build Tool Settings: SLASH_JAVA = c:/OpenJDK ALT_SLASH_JAVA = c:/OpenJDK VARIANT = OPT JDK_DEVTOOLS_DIR = c:/OpenJDK/devtools ALT_JDK_DEVTOOLS_DIR = ANT_HOME = c:/OpenJDK/apache-ant-1.7.1 UNIXCOMMAND_PATH = /usr/bin/ ALT_UNIXCOMMAND_PATH = COMPILER_PATH = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/ ALT_COMPILER_PATH = DEVTOOLS_PATH = /usr/bin/ ALT_DEVTOOLS_PATH = MSVCRNN_DLL_PATH = C:/PROGRA~2/MICROS~2.0/Vc/redist/x64/Microsoft.VC100.CRT ALT_MSVCRNN_DLL_PATH = INCLUDE = C:/PROGRA~2/MICROS~2.0/VC/include;C:/MSSDKWIN7/Windows/v7.1/Include LIB = C:/PROGRA~2/MICROS~2.0/VC/lib/amd64;C:/MSSDKWIN7/Windows/v7.1/Lib/x64 COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) COMPILER_VERSION = VS2010 CC_VER = 16.00.40219.01 [requires at least 16.00.30319.01] ZIP_VER = 3.0 [requires at least 2.2] UNZIP_VER = 6.00 [requires at least 5.12] LINK_VER = 10.00.40219.01 [requires at least 10.00.30319.01] CC = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/cl LINK = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link DUMPBIN = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe ANT_VER = 1.7.1 [requires at least 1.7.1] TEMPDIR = C:/OpenJDK/openjdk/build/windows-amd64/tmp Build Directives: OPENJDK = true USE_HOTSPOT_INTERPRETER_MODE = PEDANTIC = DEV_ONLY = NO_DOCS = NO_IMAGES = TOOLS_ONLY = INSANE = COMPILE_APPROACH = normal FASTDEBUG = COMPILER_WARNINGS_FATAL = false COMPILER_WARNING_LEVEL = 3 SHOW_ALL_WARNINGS = false INCREMENTAL_BUILD = false CC_HIGHEST_OPT = CC_HIGHER_OPT = CC_LOWER_OPT = CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE BOOT_JAVA_CMD = c:/OpenJDK/jdk-6u18/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m BOOT_JAVAC_CMD = c:/OpenJDK/jdk-6u18/bin/javac -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 -XDignore.symbol.file=true BOOT_JAR_CMD = c:/OpenJDK/jdk-6u18/bin/jar BOOT_JARSIGNER_CMD = c:/OpenJDK/jdk-6u18/bin/jarsigner Build Platform Settings: USER = Administrator PLATFORM = windows ARCH = amd64 LIBARCH = amd64 ARCH_FAMILY = amd64 ARCH_DATA_MODEL = 64 ARCHPROP = amd64 PROCESSOR_ARCHITECTURE = x86 PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 26 Stepping 5, GenuineIntel USING_CYGWIN = true CYGWIN_VER = 6.1 [requires at least 4.0] CYGPATH_CMD = cygpath -a -s -m OS_VERSION = 6.1 [requires at least 5.2] OS_VARIANT_NAME = OS_VARIANT_VERSION = 6.1 MB_OF_MEMORY = 8191 GNU Make Settings: MAKE = make MAKE_VER = 3.82 [requires at least 3.81] MAKECMDGOALS = sanity MAKEFLAGS = w SHELL = /bin/sh Target Build Versions: JDK_VERSION = 1.7.0 MILESTONE = internal RELEASE = 1.7.0-internal FULL_VERSION = 1.7.0-internal-administrator_2013_02_06_23_32-b00 BUILD_NUMBER = b00 External File/Binary Locations: USRJDKINSTANCES_PATH = C:/PROGRA~1/Java BUILD_JDK_IMPORT_PATH = c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries ALT_BUILD_JDK_IMPORT_PATH = JDK_IMPORT_PATH = c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries/windows-amd64 ALT_JDK_IMPORT_PATH = LANGTOOLS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist ALT_LANGTOOLS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist ALT_CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist ALT_JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist ALT_JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR ALT_HOTSPOT_DOCS_IMPORT_PATH = HOTSPOT_IMPORT_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import ALT_HOTSPOT_IMPORT_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import HOTSPOT_SERVER_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/jre/bin/server ALT_HOTSPOT_SERVER_PATH = HOTSPOT_LIB_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/lib ALT_HOTSPOT_LIB_PATH = DXSDK_VER = 0x0900 DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 ALT_DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 DXSDK_INCLUDE_PATH = C:/PROGRA~2/MI4ADD~1/Include ALT_DXSDK_INCLUDE_PATH = DXSDK_LIB_PATH = C:/PROGRA~2/MI4ADD~1/Lib/x64 ALT_DXSDK_LIB_PATH = WINDOWSSDKDIR = C:/PROGRA~2/MICROS~1/Windows/v7.0a/ ALT_WINDOWSSDKDIR = RC = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/RC.Exe REBASE = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/ReBase.Exe CACERTS_FILE = ./../src/share/lib/security/cacerts ALT_CACERTS_FILE = OpenJDK-specific settings: FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include ALT_FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 ALT_FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 Previous JDK Settings: PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE ALT_PREVIOUS_RELEASE_PATH = PREVIOUS_JDK_VERSION = 1.6.0 ALT_PREVIOUS_JDK_VERSION = PREVIOUS_JDK_FILE = ALT_PREVIOUS_JDK_FILE = PREVIOUS_JRE_FILE = ALT_PREVIOUS_JRE_FILE = PREVIOUS_RELEASE_IMAGE = c:/OpenJDK/jdk-6u18 ALT_PREVIOUS_RELEASE_IMAGE = WARNING: To build Java 2 SDK 1.7.0 you need : VS2010 - link.exe version '10.00.30319.01' Specifically the Visual Studio 10 link.exe. You appear to be using Linker version '10.00.40219.01' Sanity check passed. make \ SKIP_FASTDEBUG_BUILD=true \ SKIP_DEBUG_BUILD=true \ \ generic_build_repo_series make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk' /usr/bin/mkdir -p ./build/windows-amd64/j2sdk-image /usr/bin/mkdir -p C:/OpenJDK/openjdk/build/windows-amd64/langtools == End of listing of make sanity portion of build == From volker.simonis at gmail.com Thu Feb 7 09:36:28 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Feb 2013 10:36:28 +0100 Subject: Hang building JDK 7 Hotspot in Windows 7 In-Reply-To: <1AC3281AD57A34468B9879C754022CAF05F1497130@exchange.vocera.local> References: <1AC3281AD57A34468B9879C754022CAF05F1497130@exchange.vocera.local> Message-ID: Hi Randy, this problems pops up every now and then but unfortunately (at least to my knowledge) there exists no real solution for it. You can read the following comment on my blog which describes a similar problem and my answer to it which describes different workarounds: http://weblogs.java.net/blog/simonis/archive/2011/10/28/yaojowbi-yet-another-openjdk-windows-build-instruction#comment-824742 Regards, Volker On Thu, Feb 7, 2013 at 8:59 AM, Randy Nielsen wrote: > I am thoroughly stuck building JDK 7 when I start the Hotspot portion of the build. This is Windows 7 64 bit building 64 bit JDK with Visual Studio 10 Service Pack 1. The hang seems to happen immediately after I start the hotspot portion of the make. There is no output at all. Watching the Windows Task Manager in the Processes tab shows the System Idle process at 99% almost all of the time. Occasionally mscorsvw.exe (.NET services) or minty.exe gets a few % of CPU but only very briefly. > > >From browsing the web I've tried the following "fixes": verified that there was no anti-virus program, and disabled ASLR (Address Space Layout Randomization). No change in behavior. > > Has anyone any ideas about how to deal with this? Also are there settings in the make that will dramatically increase the level of logging in the make that might help me debug this? > > Here's the output of the make hotspot: > > /usr/bin/mkdir -p C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir > /usr/bin/mkdir -p C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import > > > ######################################################################## > ######################################################################## > ##### Entering hotspot for target(s) all_product ##### > ######################################################################## > > cd ./hotspot/make && \ > make JDK_TOPDIR=C:/OpenJDK/openjdk/jdk JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir ALT_EXPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import ALT_SLASH_JAVA="c:/OpenJDK" ALT_BOOTDIR=c:/OpenJDK/jdk-6u18 ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist all_product > > ==>> That's it - no more output. > > The output of the sanity portion of the make is below. > > Hoping someone can help! > > Randy > > $ make > cygwin warning: > MS-DOS style path detected: C:/Windows/system32/wscript.exe > Preferred POSIX equivalent is: /cygdrive/c/Windows/system32/wscript.exe > CYGWIN environment variable option "nodosfilewarning" turns off this warning. > Consult the user's guide for more details about POSIX paths: > http://cygwin.com/cygwin-ug-net/using.html#using-pathnames > ( cd ./jdk/make && \ > make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=C:/OpenJDK/openjdk/jdk JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64 ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist ALT_CORBA_DIST=C:/OpenJDK/openjdk/build/windows-amd64/corba/dist ALT_JAXP_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist ALT_JAXWS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist ALT_HOTSPOT_IMPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import BUILD_HOTSPOT=true ; ) > make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' > make[1]: Leaving directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' > > Build Machine Information: > build machine = WIN-R7HSHTAIIHC > > Build Directory Structure: > CWD = /cygdrive/c/OpenJDK/openjdk > TOPDIR = . > LANGTOOLS_TOPDIR = ./langtools > JAXP_TOPDIR = ./jaxp > JAXWS_TOPDIR = ./jaxws > CORBA_TOPDIR = ./corba > HOTSPOT_TOPDIR = ./hotspot > JDK_TOPDIR = ./jdk > > Build Directives: > BUILD_LANGTOOLS = true > BUILD_JAXP = true > BUILD_JAXWS = true > BUILD_CORBA = true > BUILD_HOTSPOT = true > BUILD_JDK = true > DEBUG_CLASSFILES = > DEBUG_BINARIES = > > Hotspot Settings: > HOTSPOT_BUILD_JOBS = > HOTSPOT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir > HOTSPOT_EXPORT_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import > > > > > Bootstrap Settings: > BOOTDIR = c:/OpenJDK/jdk-6u18 > ALT_BOOTDIR = c:/OpenJDK/jdk-6u18 > BOOT_VER = 1.6.0 [requires at least 1.6] > OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 > ALT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 > ABS_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 > > Build Tool Settings: > SLASH_JAVA = c:/OpenJDK > ALT_SLASH_JAVA = c:/OpenJDK > VARIANT = OPT > JDK_DEVTOOLS_DIR = c:/OpenJDK/devtools > ALT_JDK_DEVTOOLS_DIR = > ANT_HOME = c:/OpenJDK/apache-ant-1.7.1 > UNIXCOMMAND_PATH = /usr/bin/ > ALT_UNIXCOMMAND_PATH = > COMPILER_PATH = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/ > ALT_COMPILER_PATH = > DEVTOOLS_PATH = /usr/bin/ > ALT_DEVTOOLS_PATH = > MSVCRNN_DLL_PATH = C:/PROGRA~2/MICROS~2.0/Vc/redist/x64/Microsoft.VC100.CRT > ALT_MSVCRNN_DLL_PATH = > INCLUDE = C:/PROGRA~2/MICROS~2.0/VC/include;C:/MSSDKWIN7/Windows/v7.1/Include > LIB = C:/PROGRA~2/MICROS~2.0/VC/lib/amd64;C:/MSSDKWIN7/Windows/v7.1/Lib/x64 > COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) > COMPILER_VERSION = VS2010 > CC_VER = 16.00.40219.01 [requires at least 16.00.30319.01] > ZIP_VER = 3.0 [requires at least 2.2] > UNZIP_VER = 6.00 [requires at least 5.12] > LINK_VER = 10.00.40219.01 [requires at least 10.00.30319.01] > CC = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/cl > LINK = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link > DUMPBIN = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe > ANT_VER = 1.7.1 [requires at least 1.7.1] > TEMPDIR = C:/OpenJDK/openjdk/build/windows-amd64/tmp > > Build Directives: > OPENJDK = true > USE_HOTSPOT_INTERPRETER_MODE = > PEDANTIC = > DEV_ONLY = > NO_DOCS = > NO_IMAGES = > TOOLS_ONLY = > INSANE = > COMPILE_APPROACH = normal > FASTDEBUG = > COMPILER_WARNINGS_FATAL = false > COMPILER_WARNING_LEVEL = 3 > SHOW_ALL_WARNINGS = false > INCREMENTAL_BUILD = false > CC_HIGHEST_OPT = > CC_HIGHER_OPT = > CC_LOWER_OPT = > CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE > CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE > BOOT_JAVA_CMD = c:/OpenJDK/jdk-6u18/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m > BOOT_JAVAC_CMD = c:/OpenJDK/jdk-6u18/bin/javac -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 -XDignore.symbol.file=true > BOOT_JAR_CMD = c:/OpenJDK/jdk-6u18/bin/jar > BOOT_JARSIGNER_CMD = c:/OpenJDK/jdk-6u18/bin/jarsigner > > Build Platform Settings: > USER = Administrator > PLATFORM = windows > ARCH = amd64 > LIBARCH = amd64 > ARCH_FAMILY = amd64 > ARCH_DATA_MODEL = 64 > ARCHPROP = amd64 > PROCESSOR_ARCHITECTURE = x86 > PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 26 Stepping 5, GenuineIntel > USING_CYGWIN = true > CYGWIN_VER = 6.1 [requires at least 4.0] > CYGPATH_CMD = cygpath -a -s -m > OS_VERSION = 6.1 [requires at least 5.2] > OS_VARIANT_NAME = > OS_VARIANT_VERSION = 6.1 > MB_OF_MEMORY = 8191 > > GNU Make Settings: > MAKE = make > MAKE_VER = 3.82 [requires at least 3.81] > MAKECMDGOALS = sanity > MAKEFLAGS = w > SHELL = /bin/sh > > Target Build Versions: > JDK_VERSION = 1.7.0 > MILESTONE = internal > RELEASE = 1.7.0-internal > FULL_VERSION = 1.7.0-internal-administrator_2013_02_06_23_32-b00 > BUILD_NUMBER = b00 > > External File/Binary Locations: > USRJDKINSTANCES_PATH = C:/PROGRA~1/Java > BUILD_JDK_IMPORT_PATH = c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries > ALT_BUILD_JDK_IMPORT_PATH = > JDK_IMPORT_PATH = c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries/windows-amd64 > ALT_JDK_IMPORT_PATH = > LANGTOOLS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist > ALT_LANGTOOLS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist > CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist > ALT_CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist > JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist > ALT_JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist > JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist > ALT_JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist > HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR > ALT_HOTSPOT_DOCS_IMPORT_PATH = > HOTSPOT_IMPORT_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import > ALT_HOTSPOT_IMPORT_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import > HOTSPOT_SERVER_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/jre/bin/server > ALT_HOTSPOT_SERVER_PATH = > HOTSPOT_LIB_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/lib > ALT_HOTSPOT_LIB_PATH = > DXSDK_VER = 0x0900 > DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 > ALT_DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 > DXSDK_INCLUDE_PATH = C:/PROGRA~2/MI4ADD~1/Include > ALT_DXSDK_INCLUDE_PATH = > DXSDK_LIB_PATH = C:/PROGRA~2/MI4ADD~1/Lib/x64 > ALT_DXSDK_LIB_PATH = > WINDOWSSDKDIR = C:/PROGRA~2/MICROS~1/Windows/v7.0a/ > ALT_WINDOWSSDKDIR = > RC = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/RC.Exe > REBASE = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/ReBase.Exe > CACERTS_FILE = ./../src/share/lib/security/cacerts > ALT_CACERTS_FILE = > > OpenJDK-specific settings: > FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include > ALT_FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include > FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 > ALT_FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 > > Previous JDK Settings: > PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE > ALT_PREVIOUS_RELEASE_PATH = > PREVIOUS_JDK_VERSION = 1.6.0 > ALT_PREVIOUS_JDK_VERSION = > PREVIOUS_JDK_FILE = > ALT_PREVIOUS_JDK_FILE = > PREVIOUS_JRE_FILE = > ALT_PREVIOUS_JRE_FILE = > PREVIOUS_RELEASE_IMAGE = c:/OpenJDK/jdk-6u18 > ALT_PREVIOUS_RELEASE_IMAGE = > > > WARNING: To build Java 2 SDK 1.7.0 you need : > VS2010 - link.exe version '10.00.30319.01' > Specifically the Visual Studio 10 link.exe. > You appear to be using Linker version '10.00.40219.01' > > Sanity check passed. > make \ > SKIP_FASTDEBUG_BUILD=true \ > SKIP_DEBUG_BUILD=true \ > \ > generic_build_repo_series > make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk' > /usr/bin/mkdir -p ./build/windows-amd64/j2sdk-image > /usr/bin/mkdir -p C:/OpenJDK/openjdk/build/windows-amd64/langtools > > == End of listing of make sanity portion of build == > > From kelly.ohair at oracle.com Thu Feb 7 16:36:20 2013 From: kelly.ohair at oracle.com (Kelly Ohair) Date: Thu, 7 Feb 2013 08:36:20 -0800 Subject: Hang building JDK 7 Hotspot in Windows 7 In-Reply-To: <1AC3281AD57A34468B9879C754022CAF05F1497130@exchange.vocera.local> References: <1AC3281AD57A34468B9879C754022CAF05F1497130@exchange.vocera.local> Message-ID: <29D2F8E5-D2E7-441F-86C7-63888F114A8F@oracle.com> no definite answers just ideas we are starting to use windows 2008R2 which seems better make sure the env vars TMP and TEMP are set to directories windows understands eg C:/ paths and these directories exist and have write permissions try using make LOG=debug,nofile Sent from my iPhone On Feb 6, 2013, at 23:59, Randy Nielsen wrote: > I am thoroughly stuck building JDK 7 when I start the Hotspot portion of the build. This is Windows 7 64 bit building 64 bit JDK with Visual Studio 10 Service Pack 1. The hang seems to happen immediately after I start the hotspot portion of the make. There is no output at all. Watching the Windows Task Manager in the Processes tab shows the System Idle process at 99% almost all of the time. Occasionally mscorsvw.exe (.NET services) or minty.exe gets a few % of CPU but only very briefly. > >> From browsing the web I've tried the following "fixes": verified that there was no anti-virus program, and disabled ASLR (Address Space Layout Randomization). No change in behavior. > > Has anyone any ideas about how to deal with this? Also are there settings in the make that will dramatically increase the level of logging in the make that might help me debug this? > > Here's the output of the make hotspot: > > /usr/bin/mkdir -p C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir > /usr/bin/mkdir -p C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import > > > ######################################################################## > ######################################################################## > ##### Entering hotspot for target(s) all_product ##### > ######################################################################## > > cd ./hotspot/make && \ > make JDK_TOPDIR=C:/OpenJDK/openjdk/jdk JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir ALT_EXPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import ALT_SLASH_JAVA="c:/OpenJDK" ALT_BOOTDIR=c:/OpenJDK/jdk-6u18 ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist all_product > > ==>> That's it - no more output. > > The output of the sanity portion of the make is below. > > Hoping someone can help! > > Randy > > $ make > cygwin warning: > MS-DOS style path detected: C:/Windows/system32/wscript.exe > Preferred POSIX equivalent is: /cygdrive/c/Windows/system32/wscript.exe > CYGWIN environment variable option "nodosfilewarning" turns off this warning. > Consult the user's guide for more details about POSIX paths: > http://cygwin.com/cygwin-ug-net/using.html#using-pathnames > ( cd ./jdk/make && \ > make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=C:/OpenJDK/openjdk/jdk JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64 ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist ALT_CORBA_DIST=C:/OpenJDK/openjdk/build/windows-amd64/corba/dist ALT_JAXP_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist ALT_JAXWS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist ALT_HOTSPOT_IMPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import BUILD_HOTSPOT=true ; ) > make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' > make[1]: Leaving directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' > > Build Machine Information: > build machine = WIN-R7HSHTAIIHC > > Build Directory Structure: > CWD = /cygdrive/c/OpenJDK/openjdk > TOPDIR = . > LANGTOOLS_TOPDIR = ./langtools > JAXP_TOPDIR = ./jaxp > JAXWS_TOPDIR = ./jaxws > CORBA_TOPDIR = ./corba > HOTSPOT_TOPDIR = ./hotspot > JDK_TOPDIR = ./jdk > > Build Directives: > BUILD_LANGTOOLS = true > BUILD_JAXP = true > BUILD_JAXWS = true > BUILD_CORBA = true > BUILD_HOTSPOT = true > BUILD_JDK = true > DEBUG_CLASSFILES = > DEBUG_BINARIES = > > Hotspot Settings: > HOTSPOT_BUILD_JOBS = > HOTSPOT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir > HOTSPOT_EXPORT_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import > > > > > Bootstrap Settings: > BOOTDIR = c:/OpenJDK/jdk-6u18 > ALT_BOOTDIR = c:/OpenJDK/jdk-6u18 > BOOT_VER = 1.6.0 [requires at least 1.6] > OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 > ALT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 > ABS_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 > > Build Tool Settings: > SLASH_JAVA = c:/OpenJDK > ALT_SLASH_JAVA = c:/OpenJDK > VARIANT = OPT > JDK_DEVTOOLS_DIR = c:/OpenJDK/devtools > ALT_JDK_DEVTOOLS_DIR = > ANT_HOME = c:/OpenJDK/apache-ant-1.7.1 > UNIXCOMMAND_PATH = /usr/bin/ > ALT_UNIXCOMMAND_PATH = > COMPILER_PATH = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/ > ALT_COMPILER_PATH = > DEVTOOLS_PATH = /usr/bin/ > ALT_DEVTOOLS_PATH = > MSVCRNN_DLL_PATH = C:/PROGRA~2/MICROS~2.0/Vc/redist/x64/Microsoft.VC100.CRT > ALT_MSVCRNN_DLL_PATH = > INCLUDE = C:/PROGRA~2/MICROS~2.0/VC/include;C:/MSSDKWIN7/Windows/v7.1/Include > LIB = C:/PROGRA~2/MICROS~2.0/VC/lib/amd64;C:/MSSDKWIN7/Windows/v7.1/Lib/x64 > COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) > COMPILER_VERSION = VS2010 > CC_VER = 16.00.40219.01 [requires at least 16.00.30319.01] > ZIP_VER = 3.0 [requires at least 2.2] > UNZIP_VER = 6.00 [requires at least 5.12] > LINK_VER = 10.00.40219.01 [requires at least 10.00.30319.01] > CC = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/cl > LINK = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link > DUMPBIN = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe > ANT_VER = 1.7.1 [requires at least 1.7.1] > TEMPDIR = C:/OpenJDK/openjdk/build/windows-amd64/tmp > > Build Directives: > OPENJDK = true > USE_HOTSPOT_INTERPRETER_MODE = > PEDANTIC = > DEV_ONLY = > NO_DOCS = > NO_IMAGES = > TOOLS_ONLY = > INSANE = > COMPILE_APPROACH = normal > FASTDEBUG = > COMPILER_WARNINGS_FATAL = false > COMPILER_WARNING_LEVEL = 3 > SHOW_ALL_WARNINGS = false > INCREMENTAL_BUILD = false > CC_HIGHEST_OPT = > CC_HIGHER_OPT = > CC_LOWER_OPT = > CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE > CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE > BOOT_JAVA_CMD = c:/OpenJDK/jdk-6u18/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m > BOOT_JAVAC_CMD = c:/OpenJDK/jdk-6u18/bin/javac -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 -XDignore.symbol.file=true > BOOT_JAR_CMD = c:/OpenJDK/jdk-6u18/bin/jar > BOOT_JARSIGNER_CMD = c:/OpenJDK/jdk-6u18/bin/jarsigner > > Build Platform Settings: > USER = Administrator > PLATFORM = windows > ARCH = amd64 > LIBARCH = amd64 > ARCH_FAMILY = amd64 > ARCH_DATA_MODEL = 64 > ARCHPROP = amd64 > PROCESSOR_ARCHITECTURE = x86 > PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 26 Stepping 5, GenuineIntel > USING_CYGWIN = true > CYGWIN_VER = 6.1 [requires at least 4.0] > CYGPATH_CMD = cygpath -a -s -m > OS_VERSION = 6.1 [requires at least 5.2] > OS_VARIANT_NAME = > OS_VARIANT_VERSION = 6.1 > MB_OF_MEMORY = 8191 > > GNU Make Settings: > MAKE = make > MAKE_VER = 3.82 [requires at least 3.81] > MAKECMDGOALS = sanity > MAKEFLAGS = w > SHELL = /bin/sh > > Target Build Versions: > JDK_VERSION = 1.7.0 > MILESTONE = internal > RELEASE = 1.7.0-internal > FULL_VERSION = 1.7.0-internal-administrator_2013_02_06_23_32-b00 > BUILD_NUMBER = b00 > > External File/Binary Locations: > USRJDKINSTANCES_PATH = C:/PROGRA~1/Java > BUILD_JDK_IMPORT_PATH = c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries > ALT_BUILD_JDK_IMPORT_PATH = > JDK_IMPORT_PATH = c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries/windows-amd64 > ALT_JDK_IMPORT_PATH = > LANGTOOLS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist > ALT_LANGTOOLS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist > CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist > ALT_CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist > JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist > ALT_JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist > JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist > ALT_JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist > HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR > ALT_HOTSPOT_DOCS_IMPORT_PATH = > HOTSPOT_IMPORT_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import > ALT_HOTSPOT_IMPORT_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import > HOTSPOT_SERVER_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/jre/bin/server > ALT_HOTSPOT_SERVER_PATH = > HOTSPOT_LIB_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/lib > ALT_HOTSPOT_LIB_PATH = > DXSDK_VER = 0x0900 > DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 > ALT_DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 > DXSDK_INCLUDE_PATH = C:/PROGRA~2/MI4ADD~1/Include > ALT_DXSDK_INCLUDE_PATH = > DXSDK_LIB_PATH = C:/PROGRA~2/MI4ADD~1/Lib/x64 > ALT_DXSDK_LIB_PATH = > WINDOWSSDKDIR = C:/PROGRA~2/MICROS~1/Windows/v7.0a/ > ALT_WINDOWSSDKDIR = > RC = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/RC.Exe > REBASE = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/ReBase.Exe > CACERTS_FILE = ./../src/share/lib/security/cacerts > ALT_CACERTS_FILE = > > OpenJDK-specific settings: > FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include > ALT_FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include > FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 > ALT_FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 > > Previous JDK Settings: > PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE > ALT_PREVIOUS_RELEASE_PATH = > PREVIOUS_JDK_VERSION = 1.6.0 > ALT_PREVIOUS_JDK_VERSION = > PREVIOUS_JDK_FILE = > ALT_PREVIOUS_JDK_FILE = > PREVIOUS_JRE_FILE = > ALT_PREVIOUS_JRE_FILE = > PREVIOUS_RELEASE_IMAGE = c:/OpenJDK/jdk-6u18 > ALT_PREVIOUS_RELEASE_IMAGE = > > > WARNING: To build Java 2 SDK 1.7.0 you need : > VS2010 - link.exe version '10.00.30319.01' > Specifically the Visual Studio 10 link.exe. > You appear to be using Linker version '10.00.40219.01' > > Sanity check passed. > make \ > SKIP_FASTDEBUG_BUILD=true \ > SKIP_DEBUG_BUILD=true \ > \ > generic_build_repo_series > make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk' > /usr/bin/mkdir -p ./build/windows-amd64/j2sdk-image > /usr/bin/mkdir -p C:/OpenJDK/openjdk/build/windows-amd64/langtools > > == End of listing of make sanity portion of build == > > From peter.brunet at oracle.com Thu Feb 7 20:18:48 2013 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 07 Feb 2013 14:18:48 -0600 Subject: building JDK6 - latest usable compiler Message-ID: <51140C28.3030005@oracle.com> Hi I have VS 2010 and need to build JDK6. Using my typical JDK7 set up with VS 2010 make sanity reports ../make/common/shared/Compiler-msvc.gmk:129 *** COMPILER_PATH cannot be empty here. Stop. Do I need to install an older compiler (and if so where would I get it)? Pete From philip.race at oracle.com Thu Feb 7 20:40:27 2013 From: philip.race at oracle.com (Phil Race) Date: Thu, 07 Feb 2013 12:40:27 -0800 Subject: building JDK6 - latest usable compiler In-Reply-To: <51140C28.3030005@oracle.com> References: <51140C28.3030005@oracle.com> Message-ID: <5114113B.3010006@oracle.com> Yes you need VS2003. At this point your best bet to get it may be ebay :-) -phil. On 2/7/2013 12:18 PM, Pete Brunet wrote: > Hi I have VS 2010 and need to build JDK6. Using my typical JDK7 set up > with VS 2010 make sanity reports > > ../make/common/shared/Compiler-msvc.gmk:129 *** COMPILER_PATH cannot be > empty here. Stop. > > Do I need to install an older compiler (and if so where would I get it)? > > Pete From tim.bell at oracle.com Thu Feb 7 20:59:11 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 07 Feb 2013 12:59:11 -0800 Subject: building JDK6 - latest usable compiler In-Reply-To: <51140C28.3030005@oracle.com> References: <51140C28.3030005@oracle.com> Message-ID: <5114159F.3040601@oracle.com> On 02/07/13 12:18, Pete Brunet wrote: > Hi I have VS 2010 and need to build JDK6. Using my typical JDK7 set up > with VS 2010 make sanity reports > > ../make/common/shared/Compiler-msvc.gmk:129 *** COMPILER_PATH cannot be > empty here. Stop. > > Do I need to install an older compiler (and if so where would I get it)? JDK6 is built with Microsoft Visual Studio .NET 2003 Professional for 32-bit Windows and Microsoft Platform SDK April 2005 for 64-bit Windows: http://hg.openjdk.java.net/jdk6/jdk6/raw-file/f30a5896c305/README-builds.html#msvc There were O/S requirements also: Windows 2000 SP2 for 32-bit and I believe it was Windows 2003 for 64-bit. Can you submit your builds to the sustaining JPRT queue? There are some legacy Windows build systems available there that are still used to build 6-update releases. You might be able to avoid the trouble of setting up your own legacy system. Tim From peter.brunet at oracle.com Thu Feb 7 21:04:31 2013 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 07 Feb 2013 15:04:31 -0600 Subject: building JDK6 - latest usable compiler In-Reply-To: <5114159F.3040601@oracle.com> References: <51140C28.3030005@oracle.com> <5114159F.3040601@oracle.com> Message-ID: <511416DF.6060504@oracle.com> On 2/7/13 2:59 PM, Tim Bell wrote: > On 02/07/13 12:18, Pete Brunet wrote: >> Hi I have VS 2010 and need to build JDK6. Using my typical JDK7 set up >> with VS 2010 make sanity reports >> >> ../make/common/shared/Compiler-msvc.gmk:129 *** COMPILER_PATH cannot be >> empty here. Stop. >> >> Do I need to install an older compiler (and if so where would I get it)? > > JDK6 is built with Microsoft Visual Studio .NET 2003 Professional for > 32-bit Windows and Microsoft Platform SDK April 2005 for 64-bit Windows: > > http://hg.openjdk.java.net/jdk6/jdk6/raw-file/f30a5896c305/README-builds.html#msvc > > > There were O/S requirements also: Windows 2000 SP2 for 32-bit and I > believe it was Windows 2003 for 64-bit. > > Can you submit your builds to the sustaining JPRT queue? There are > some legacy Windows build systems available there that are still used > to build 6-update releases. You might be able to avoid the trouble of > setting up your own legacy system. I started down the other path, but based on what you said I think that's going to be a lot more time consuming than using JPRT. I did a 7 based JPRT build for the first time a couple weeks back. Let me see if I can figure out how to do one for 6. > > Tim > > > From rnielsen at vocera.com Thu Feb 7 23:47:28 2013 From: rnielsen at vocera.com (Randy Nielsen) Date: Thu, 7 Feb 2013 15:47:28 -0800 Subject: Hang building JDK 7 Hotspot in Windows 7 In-Reply-To: <29D2F8E5-D2E7-441F-86C7-63888F114A8F@oracle.com> References: <1AC3281AD57A34468B9879C754022CAF05F1497130@exchange.vocera.local> <29D2F8E5-D2E7-441F-86C7-63888F114A8F@oracle.com> Message-ID: <1AC3281AD57A34468B9879C754022CAF05F14975BE@exchange.vocera.local> Tried suggestions with no change. Specifically LOG=debug,nofile didn't add any output at all. Are there any others ways to poke the make to get more output, say a line by line trace of the make behavior? This feels like a process synchronization problem where process A is waiting to be notified by someone and of course the notify never occurs. But why would a bunch of compiles etc. use this kind of synchronization? Also I tried strace to peek under the covers, and concluded that Cygwin strace is very buggy. Details (optional) follow, after my signature. Randy I ran strace on top of the make of hotspot and to my utter astonishment after a few seconds it ended like this: $ strace make hotspot >strace.txt /bin/sh: C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link: Function not implemented jdk/make/common/shared/Compiler-msvc.gmk:80: *** COMPILER_VERSION cannot be empty here. Stop. Being a suspicious soul I then tried this: $ strace make sanity >trace.txt /bin/sh: C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link: Function not implemented jdk/make/common/shared/Compiler-msvc.gmk:80: *** COMPILER_VERSION cannot be empty here. Stop. Of course the "make sanity" without strace works perfectly. Conclusion: the Cygwin strace is buggy (big surprise) and can't be used to help peer "under the covers" of the hotspot make. -----Original Message----- From: Kelly Ohair [mailto:kelly.ohair at oracle.com] Sent: Thursday, February 07, 2013 8:36 AM To: Randy Nielsen Cc: build-dev at openjdk.java.net Subject: Re: Hang building JDK 7 Hotspot in Windows 7 no definite answers just ideas we are starting to use windows 2008R2 which seems better make sure the env vars TMP and TEMP are set to directories windows understands eg C:/ paths and these directories exist and have write permissions try using make LOG=debug,nofile Sent from my iPhone On Feb 6, 2013, at 23:59, Randy Nielsen wrote: > I am thoroughly stuck building JDK 7 when I start the Hotspot portion of the build. This is Windows 7 64 bit building 64 bit JDK with Visual Studio 10 Service Pack 1. The hang seems to happen immediately after I start the hotspot portion of the make. There is no output at all. Watching the Windows Task Manager in the Processes tab shows the System Idle process at 99% almost all of the time. Occasionally mscorsvw.exe (.NET services) or minty.exe gets a few % of CPU but only very briefly. > >> From browsing the web I've tried the following "fixes": verified that there was no anti-virus program, and disabled ASLR (Address Space Layout Randomization). No change in behavior. > > Has anyone any ideas about how to deal with this? Also are there settings in the make that will dramatically increase the level of logging in the make that might help me debug this? > > Here's the output of the make hotspot: > > /usr/bin/mkdir -p > C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir > /usr/bin/mkdir -p > C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import > > > ###################################################################### > ## > ######################################################################## > ##### Entering hotspot for target(s) all_product ##### > ###################################################################### > ## > > cd ./hotspot/make && \ > make JDK_TOPDIR=C:/OpenJDK/openjdk/jdk > JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared > EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 > TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 > JDK_BUILD_NUMBER=b00 > FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 > PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 > JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 > PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 > PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 > ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" > ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir > ALT_EXPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import > ALT_SLASH_JAVA="c:/OpenJDK" ALT_BOOTDIR=c:/OpenJDK/jdk-6u18 > ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/di > st all_product > > ==>> That's it - no more output. > > The output of the sanity portion of the make is below. > > Hoping someone can help! > > Randy > > $ make > cygwin warning: > MS-DOS style path detected: C:/Windows/system32/wscript.exe > Preferred POSIX equivalent is: > /cygdrive/c/Windows/system32/wscript.exe > CYGWIN environment variable option "nodosfilewarning" turns off this warning. > Consult the user's guide for more details about POSIX paths: > http://cygwin.com/cygwin-ug-net/using.html#using-pathnames > ( cd ./jdk/make && \ > make sanity HOTSPOT_IMPORT_CHECK=false > JDK_TOPDIR=C:/OpenJDK/openjdk/jdk > JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared > EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 > TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 > JDK_BUILD_NUMBER=b00 > FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 > PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 > JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 > PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 > PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 > ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" > ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64 > ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/di > st ALT_CORBA_DIST=C:/OpenJDK/openjdk/build/windows-amd64/corba/dist > ALT_JAXP_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist > ALT_JAXWS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist > ALT_HOTSPOT_IMPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot > /import BUILD_HOTSPOT=true ; ) > make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' > make[1]: Leaving directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' > > Build Machine Information: > build machine = WIN-R7HSHTAIIHC > > Build Directory Structure: > CWD = /cygdrive/c/OpenJDK/openjdk > TOPDIR = . > LANGTOOLS_TOPDIR = ./langtools > JAXP_TOPDIR = ./jaxp > JAXWS_TOPDIR = ./jaxws > CORBA_TOPDIR = ./corba > HOTSPOT_TOPDIR = ./hotspot > JDK_TOPDIR = ./jdk > > Build Directives: > BUILD_LANGTOOLS = true > BUILD_JAXP = true > BUILD_JAXWS = true > BUILD_CORBA = true > BUILD_HOTSPOT = true > BUILD_JDK = true > DEBUG_CLASSFILES = > DEBUG_BINARIES = > > Hotspot Settings: > HOTSPOT_BUILD_JOBS = > HOTSPOT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir > HOTSPOT_EXPORT_PATH = > C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import > > > > > Bootstrap Settings: > BOOTDIR = c:/OpenJDK/jdk-6u18 > ALT_BOOTDIR = c:/OpenJDK/jdk-6u18 > BOOT_VER = 1.6.0 [requires at least 1.6] OUTPUTDIR = > C:/OpenJDK/openjdk/build/windows-amd64 > ALT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 > ABS_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 > > Build Tool Settings: > SLASH_JAVA = c:/OpenJDK > ALT_SLASH_JAVA = c:/OpenJDK > VARIANT = OPT > JDK_DEVTOOLS_DIR = c:/OpenJDK/devtools > ALT_JDK_DEVTOOLS_DIR = > ANT_HOME = c:/OpenJDK/apache-ant-1.7.1 UNIXCOMMAND_PATH = /usr/bin/ > ALT_UNIXCOMMAND_PATH = > COMPILER_PATH = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/ > ALT_COMPILER_PATH = > DEVTOOLS_PATH = /usr/bin/ > ALT_DEVTOOLS_PATH = > MSVCRNN_DLL_PATH = C:/PROGRA~2/MICROS~2.0/Vc/redist/x64/Microsoft.VC100.CRT > ALT_MSVCRNN_DLL_PATH = > INCLUDE = > C:/PROGRA~2/MICROS~2.0/VC/include;C:/MSSDKWIN7/Windows/v7.1/Include > LIB = > C:/PROGRA~2/MICROS~2.0/VC/lib/amd64;C:/MSSDKWIN7/Windows/v7.1/Lib/x64 > COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) > COMPILER_VERSION = VS2010 CC_VER = 16.00.40219.01 [requires at least > 16.00.30319.01] ZIP_VER = 3.0 [requires at least 2.2] UNZIP_VER = > 6.00 [requires at least 5.12] LINK_VER = 10.00.40219.01 [requires at > least 10.00.30319.01] CC = > C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/cl > LINK = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link > DUMPBIN = > C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe > ANT_VER = 1.7.1 [requires at least 1.7.1] TEMPDIR = > C:/OpenJDK/openjdk/build/windows-amd64/tmp > > Build Directives: > OPENJDK = true > USE_HOTSPOT_INTERPRETER_MODE = > PEDANTIC = > DEV_ONLY = > NO_DOCS = > NO_IMAGES = > TOOLS_ONLY = > INSANE = > COMPILE_APPROACH = normal > FASTDEBUG = > COMPILER_WARNINGS_FATAL = false > COMPILER_WARNING_LEVEL = 3 > SHOW_ALL_WARNINGS = false > INCREMENTAL_BUILD = false > CC_HIGHEST_OPT = > CC_HIGHER_OPT = > CC_LOWER_OPT = > CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE > CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE > BOOT_JAVA_CMD = c:/OpenJDK/jdk-6u18/bin/java -XX:-PrintVMOptions > -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m > -XX:PermSize=32m -XX:MaxPermSize=160m BOOT_JAVAC_CMD = > c:/OpenJDK/jdk-6u18/bin/javac -J-XX:ThreadStackSize=1536 > -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions > -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m > -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 > -XDignore.symbol.file=true BOOT_JAR_CMD = c:/OpenJDK/jdk-6u18/bin/jar > BOOT_JARSIGNER_CMD = c:/OpenJDK/jdk-6u18/bin/jarsigner > > Build Platform Settings: > USER = Administrator > PLATFORM = windows > ARCH = amd64 > LIBARCH = amd64 > ARCH_FAMILY = amd64 > ARCH_DATA_MODEL = 64 > ARCHPROP = amd64 > PROCESSOR_ARCHITECTURE = x86 > PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 26 Stepping 5, > GenuineIntel USING_CYGWIN = true CYGWIN_VER = 6.1 [requires at least > 4.0] CYGPATH_CMD = cygpath -a -s -m OS_VERSION = 6.1 [requires at > least 5.2] OS_VARIANT_NAME = OS_VARIANT_VERSION = 6.1 MB_OF_MEMORY > = 8191 > > GNU Make Settings: > MAKE = make > MAKE_VER = 3.82 [requires at least 3.81] MAKECMDGOALS = sanity > MAKEFLAGS = w SHELL = /bin/sh > > Target Build Versions: > JDK_VERSION = 1.7.0 > MILESTONE = internal > RELEASE = 1.7.0-internal > FULL_VERSION = 1.7.0-internal-administrator_2013_02_06_23_32-b00 > BUILD_NUMBER = b00 > > External File/Binary Locations: > USRJDKINSTANCES_PATH = C:/PROGRA~1/Java BUILD_JDK_IMPORT_PATH = > c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries > ALT_BUILD_JDK_IMPORT_PATH = > JDK_IMPORT_PATH = c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries/windows-amd64 > ALT_JDK_IMPORT_PATH = > LANGTOOLS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist > ALT_LANGTOOLS_DIST = > C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist > CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist > ALT_CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist > JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist > ALT_JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist > JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist > ALT_JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist > HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR > ALT_HOTSPOT_DOCS_IMPORT_PATH = > HOTSPOT_IMPORT_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import > ALT_HOTSPOT_IMPORT_PATH = > C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import > HOTSPOT_SERVER_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/jre/bin/server > ALT_HOTSPOT_SERVER_PATH = > HOTSPOT_LIB_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/lib > ALT_HOTSPOT_LIB_PATH = > DXSDK_VER = 0x0900 > DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 > ALT_DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 DXSDK_INCLUDE_PATH = > C:/PROGRA~2/MI4ADD~1/Include > ALT_DXSDK_INCLUDE_PATH = > DXSDK_LIB_PATH = C:/PROGRA~2/MI4ADD~1/Lib/x64 > ALT_DXSDK_LIB_PATH = > WINDOWSSDKDIR = C:/PROGRA~2/MICROS~1/Windows/v7.0a/ > ALT_WINDOWSSDKDIR = > RC = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/RC.Exe > REBASE = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/ReBase.Exe > CACERTS_FILE = ./../src/share/lib/security/cacerts > ALT_CACERTS_FILE = > > OpenJDK-specific settings: > FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include > ALT_FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include > FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 > ALT_FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 > > Previous JDK Settings: > PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE > ALT_PREVIOUS_RELEASE_PATH = > PREVIOUS_JDK_VERSION = 1.6.0 > ALT_PREVIOUS_JDK_VERSION = > PREVIOUS_JDK_FILE = > ALT_PREVIOUS_JDK_FILE = > PREVIOUS_JRE_FILE = > ALT_PREVIOUS_JRE_FILE = > PREVIOUS_RELEASE_IMAGE = c:/OpenJDK/jdk-6u18 > ALT_PREVIOUS_RELEASE_IMAGE = > > > WARNING: To build Java 2 SDK 1.7.0 you need : > VS2010 - link.exe version '10.00.30319.01' > Specifically the Visual Studio 10 link.exe. > You appear to be using Linker version '10.00.40219.01' > > Sanity check passed. > make \ > SKIP_FASTDEBUG_BUILD=true \ > SKIP_DEBUG_BUILD=true \ > \ > generic_build_repo_series > make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk' > /usr/bin/mkdir -p ./build/windows-amd64/j2sdk-image /usr/bin/mkdir -p > C:/OpenJDK/openjdk/build/windows-amd64/langtools > > == End of listing of make sanity portion of build == > > From david.holmes at oracle.com Fri Feb 8 00:39:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Feb 2013 10:39:53 +1000 Subject: Hang building JDK 7 Hotspot in Windows 7 In-Reply-To: <1AC3281AD57A34468B9879C754022CAF05F14975BE@exchange.vocera.local> References: <1AC3281AD57A34468B9879C754022CAF05F1497130@exchange.vocera.local> <29D2F8E5-D2E7-441F-86C7-63888F114A8F@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F14975BE@exchange.vocera.local> Message-ID: <51144959.60309@oracle.com> LOG=trace gives the most detail. make has a -d option but it is pretty useless due to the volume of data produced (mostly about the bizarre ways it tries to re-make files that you don't want re-made in the first place :( ). David On 8/02/2013 9:47 AM, Randy Nielsen wrote: > Tried suggestions with no change. Specifically LOG=debug,nofile didn't add any output at all. Are there any others ways to poke the make to get more output, say a line by line trace of the make behavior? This feels like a process synchronization problem where process A is waiting to be notified by someone and of course the notify never occurs. But why would a bunch of compiles etc. use this kind of synchronization? > > Also I tried strace to peek under the covers, and concluded that Cygwin strace is very buggy. Details (optional) follow, after my signature. > > Randy > > I ran strace on top of the make of hotspot and to my utter astonishment after a few seconds it ended like this: > > $ strace make hotspot>strace.txt > /bin/sh: C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link: Function not implemented > jdk/make/common/shared/Compiler-msvc.gmk:80: *** COMPILER_VERSION cannot be empty here. Stop. > > Being a suspicious soul I then tried this: > > $ strace make sanity>trace.txt > /bin/sh: C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link: Function not implemented > jdk/make/common/shared/Compiler-msvc.gmk:80: *** COMPILER_VERSION cannot be empty here. Stop. > > Of course the "make sanity" without strace works perfectly. Conclusion: the Cygwin strace is buggy (big surprise) and can't be used to help peer "under the covers" of the hotspot make. > > > -----Original Message----- > From: Kelly Ohair [mailto:kelly.ohair at oracle.com] > Sent: Thursday, February 07, 2013 8:36 AM > To: Randy Nielsen > Cc: build-dev at openjdk.java.net > Subject: Re: Hang building JDK 7 Hotspot in Windows 7 > > no definite answers just ideas > > we are starting to use windows 2008R2 which seems better make sure the env vars TMP and TEMP are set to directories windows understands eg C:/ paths and these directories exist and have write permissions try using make LOG=debug,nofile > > > Sent from my iPhone > > On Feb 6, 2013, at 23:59, Randy Nielsen wrote: > >> I am thoroughly stuck building JDK 7 when I start the Hotspot portion of the build. This is Windows 7 64 bit building 64 bit JDK with Visual Studio 10 Service Pack 1. The hang seems to happen immediately after I start the hotspot portion of the make. There is no output at all. Watching the Windows Task Manager in the Processes tab shows the System Idle process at 99% almost all of the time. Occasionally mscorsvw.exe (.NET services) or minty.exe gets a few % of CPU but only very briefly. >> >>> From browsing the web I've tried the following "fixes": verified that there was no anti-virus program, and disabled ASLR (Address Space Layout Randomization). No change in behavior. >> >> Has anyone any ideas about how to deal with this? Also are there settings in the make that will dramatically increase the level of logging in the make that might help me debug this? >> >> Here's the output of the make hotspot: >> >> /usr/bin/mkdir -p >> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >> /usr/bin/mkdir -p >> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >> >> >> ###################################################################### >> ## >> ######################################################################## >> ##### Entering hotspot for target(s) all_product ##### >> ###################################################################### >> ## >> >> cd ./hotspot/make&& \ >> make JDK_TOPDIR=C:/OpenJDK/openjdk/jdk >> JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared >> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 >> JDK_BUILD_NUMBER=b00 >> FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 >> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 >> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 >> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 >> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 >> ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" >> ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >> ALT_EXPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >> ALT_SLASH_JAVA="c:/OpenJDK" ALT_BOOTDIR=c:/OpenJDK/jdk-6u18 >> ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/di >> st all_product >> >> ==>> That's it - no more output. >> >> The output of the sanity portion of the make is below. >> >> Hoping someone can help! >> >> Randy >> >> $ make >> cygwin warning: >> MS-DOS style path detected: C:/Windows/system32/wscript.exe >> Preferred POSIX equivalent is: >> /cygdrive/c/Windows/system32/wscript.exe >> CYGWIN environment variable option "nodosfilewarning" turns off this warning. >> Consult the user's guide for more details about POSIX paths: >> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames >> ( cd ./jdk/make&& \ >> make sanity HOTSPOT_IMPORT_CHECK=false >> JDK_TOPDIR=C:/OpenJDK/openjdk/jdk >> JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared >> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 >> JDK_BUILD_NUMBER=b00 >> FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 >> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 >> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 >> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 >> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 >> ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" >> ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64 >> ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/di >> st ALT_CORBA_DIST=C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >> ALT_JAXP_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >> ALT_JAXWS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >> ALT_HOTSPOT_IMPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot >> /import BUILD_HOTSPOT=true ; ) >> make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' >> make[1]: Leaving directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' >> >> Build Machine Information: >> build machine = WIN-R7HSHTAIIHC >> >> Build Directory Structure: >> CWD = /cygdrive/c/OpenJDK/openjdk >> TOPDIR = . >> LANGTOOLS_TOPDIR = ./langtools >> JAXP_TOPDIR = ./jaxp >> JAXWS_TOPDIR = ./jaxws >> CORBA_TOPDIR = ./corba >> HOTSPOT_TOPDIR = ./hotspot >> JDK_TOPDIR = ./jdk >> >> Build Directives: >> BUILD_LANGTOOLS = true >> BUILD_JAXP = true >> BUILD_JAXWS = true >> BUILD_CORBA = true >> BUILD_HOTSPOT = true >> BUILD_JDK = true >> DEBUG_CLASSFILES = >> DEBUG_BINARIES = >> >> Hotspot Settings: >> HOTSPOT_BUILD_JOBS = >> HOTSPOT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >> HOTSPOT_EXPORT_PATH = >> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >> >> >> >> >> Bootstrap Settings: >> BOOTDIR = c:/OpenJDK/jdk-6u18 >> ALT_BOOTDIR = c:/OpenJDK/jdk-6u18 >> BOOT_VER = 1.6.0 [requires at least 1.6] OUTPUTDIR = >> C:/OpenJDK/openjdk/build/windows-amd64 >> ALT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 >> ABS_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 >> >> Build Tool Settings: >> SLASH_JAVA = c:/OpenJDK >> ALT_SLASH_JAVA = c:/OpenJDK >> VARIANT = OPT >> JDK_DEVTOOLS_DIR = c:/OpenJDK/devtools >> ALT_JDK_DEVTOOLS_DIR = >> ANT_HOME = c:/OpenJDK/apache-ant-1.7.1 UNIXCOMMAND_PATH = /usr/bin/ >> ALT_UNIXCOMMAND_PATH = >> COMPILER_PATH = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/ >> ALT_COMPILER_PATH = >> DEVTOOLS_PATH = /usr/bin/ >> ALT_DEVTOOLS_PATH = >> MSVCRNN_DLL_PATH = C:/PROGRA~2/MICROS~2.0/Vc/redist/x64/Microsoft.VC100.CRT >> ALT_MSVCRNN_DLL_PATH = >> INCLUDE = >> C:/PROGRA~2/MICROS~2.0/VC/include;C:/MSSDKWIN7/Windows/v7.1/Include >> LIB = >> C:/PROGRA~2/MICROS~2.0/VC/lib/amd64;C:/MSSDKWIN7/Windows/v7.1/Lib/x64 >> COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) >> COMPILER_VERSION = VS2010 CC_VER = 16.00.40219.01 [requires at least >> 16.00.30319.01] ZIP_VER = 3.0 [requires at least 2.2] UNZIP_VER = >> 6.00 [requires at least 5.12] LINK_VER = 10.00.40219.01 [requires at >> least 10.00.30319.01] CC = >> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/cl >> LINK = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link >> DUMPBIN = >> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe >> ANT_VER = 1.7.1 [requires at least 1.7.1] TEMPDIR = >> C:/OpenJDK/openjdk/build/windows-amd64/tmp >> >> Build Directives: >> OPENJDK = true >> USE_HOTSPOT_INTERPRETER_MODE = >> PEDANTIC = >> DEV_ONLY = >> NO_DOCS = >> NO_IMAGES = >> TOOLS_ONLY = >> INSANE = >> COMPILE_APPROACH = normal >> FASTDEBUG = >> COMPILER_WARNINGS_FATAL = false >> COMPILER_WARNING_LEVEL = 3 >> SHOW_ALL_WARNINGS = false >> INCREMENTAL_BUILD = false >> CC_HIGHEST_OPT = >> CC_HIGHER_OPT = >> CC_LOWER_OPT = >> CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >> CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >> BOOT_JAVA_CMD = c:/OpenJDK/jdk-6u18/bin/java -XX:-PrintVMOptions >> -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m >> -XX:PermSize=32m -XX:MaxPermSize=160m BOOT_JAVAC_CMD = >> c:/OpenJDK/jdk-6u18/bin/javac -J-XX:ThreadStackSize=1536 >> -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions >> -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m >> -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 >> -XDignore.symbol.file=true BOOT_JAR_CMD = c:/OpenJDK/jdk-6u18/bin/jar >> BOOT_JARSIGNER_CMD = c:/OpenJDK/jdk-6u18/bin/jarsigner >> >> Build Platform Settings: >> USER = Administrator >> PLATFORM = windows >> ARCH = amd64 >> LIBARCH = amd64 >> ARCH_FAMILY = amd64 >> ARCH_DATA_MODEL = 64 >> ARCHPROP = amd64 >> PROCESSOR_ARCHITECTURE = x86 >> PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 26 Stepping 5, >> GenuineIntel USING_CYGWIN = true CYGWIN_VER = 6.1 [requires at least >> 4.0] CYGPATH_CMD = cygpath -a -s -m OS_VERSION = 6.1 [requires at >> least 5.2] OS_VARIANT_NAME = OS_VARIANT_VERSION = 6.1 MB_OF_MEMORY >> = 8191 >> >> GNU Make Settings: >> MAKE = make >> MAKE_VER = 3.82 [requires at least 3.81] MAKECMDGOALS = sanity >> MAKEFLAGS = w SHELL = /bin/sh >> >> Target Build Versions: >> JDK_VERSION = 1.7.0 >> MILESTONE = internal >> RELEASE = 1.7.0-internal >> FULL_VERSION = 1.7.0-internal-administrator_2013_02_06_23_32-b00 >> BUILD_NUMBER = b00 >> >> External File/Binary Locations: >> USRJDKINSTANCES_PATH = C:/PROGRA~1/Java BUILD_JDK_IMPORT_PATH = >> c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries >> ALT_BUILD_JDK_IMPORT_PATH = >> JDK_IMPORT_PATH = c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries/windows-amd64 >> ALT_JDK_IMPORT_PATH = >> LANGTOOLS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist >> ALT_LANGTOOLS_DIST = >> C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist >> CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >> ALT_CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >> JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >> ALT_JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >> JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >> ALT_JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >> HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR >> ALT_HOTSPOT_DOCS_IMPORT_PATH = >> HOTSPOT_IMPORT_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >> ALT_HOTSPOT_IMPORT_PATH = >> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >> HOTSPOT_SERVER_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/jre/bin/server >> ALT_HOTSPOT_SERVER_PATH = >> HOTSPOT_LIB_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/lib >> ALT_HOTSPOT_LIB_PATH = >> DXSDK_VER = 0x0900 >> DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 >> ALT_DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 DXSDK_INCLUDE_PATH = >> C:/PROGRA~2/MI4ADD~1/Include >> ALT_DXSDK_INCLUDE_PATH = >> DXSDK_LIB_PATH = C:/PROGRA~2/MI4ADD~1/Lib/x64 >> ALT_DXSDK_LIB_PATH = >> WINDOWSSDKDIR = C:/PROGRA~2/MICROS~1/Windows/v7.0a/ >> ALT_WINDOWSSDKDIR = >> RC = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/RC.Exe >> REBASE = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/ReBase.Exe >> CACERTS_FILE = ./../src/share/lib/security/cacerts >> ALT_CACERTS_FILE = >> >> OpenJDK-specific settings: >> FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include >> ALT_FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include >> FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 >> ALT_FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 >> >> Previous JDK Settings: >> PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE >> ALT_PREVIOUS_RELEASE_PATH = >> PREVIOUS_JDK_VERSION = 1.6.0 >> ALT_PREVIOUS_JDK_VERSION = >> PREVIOUS_JDK_FILE = >> ALT_PREVIOUS_JDK_FILE = >> PREVIOUS_JRE_FILE = >> ALT_PREVIOUS_JRE_FILE = >> PREVIOUS_RELEASE_IMAGE = c:/OpenJDK/jdk-6u18 >> ALT_PREVIOUS_RELEASE_IMAGE = >> >> >> WARNING: To build Java 2 SDK 1.7.0 you need : >> VS2010 - link.exe version '10.00.30319.01' >> Specifically the Visual Studio 10 link.exe. >> You appear to be using Linker version '10.00.40219.01' >> >> Sanity check passed. >> make \ >> SKIP_FASTDEBUG_BUILD=true \ >> SKIP_DEBUG_BUILD=true \ >> \ >> generic_build_repo_series >> make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk' >> /usr/bin/mkdir -p ./build/windows-amd64/j2sdk-image /usr/bin/mkdir -p >> C:/OpenJDK/openjdk/build/windows-amd64/langtools >> >> == End of listing of make sanity portion of build == >> >> From erik.joelsson at oracle.com Fri Feb 8 07:43:33 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 08 Feb 2013 08:43:33 +0100 Subject: Hang building JDK 7 Hotspot in Windows 7 In-Reply-To: <1AC3281AD57A34468B9879C754022CAF05F14975BE@exchange.vocera.local> References: <1AC3281AD57A34468B9879C754022CAF05F1497130@exchange.vocera.local> <29D2F8E5-D2E7-441F-86C7-63888F114A8F@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F14975BE@exchange.vocera.local> Message-ID: <5114ACA5.7080908@oracle.com> The LOG=debug is JDK8 and build-infra specific. For JDK7 I don't know of a way to get more info except adding the -d or --debug flag to make, which as David says is rather useless most of the time. /Erik On 2013-02-08 00:47, Randy Nielsen wrote: > Tried suggestions with no change. Specifically LOG=debug,nofile didn't add any output at all. Are there any others ways to poke the make to get more output, say a line by line trace of the make behavior? This feels like a process synchronization problem where process A is waiting to be notified by someone and of course the notify never occurs. But why would a bunch of compiles etc. use this kind of synchronization? > > Also I tried strace to peek under the covers, and concluded that Cygwin strace is very buggy. Details (optional) follow, after my signature. > > Randy > > I ran strace on top of the make of hotspot and to my utter astonishment after a few seconds it ended like this: > > $ strace make hotspot>strace.txt > /bin/sh: C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link: Function not implemented > jdk/make/common/shared/Compiler-msvc.gmk:80: *** COMPILER_VERSION cannot be empty here. Stop. > > Being a suspicious soul I then tried this: > > $ strace make sanity>trace.txt > /bin/sh: C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link: Function not implemented > jdk/make/common/shared/Compiler-msvc.gmk:80: *** COMPILER_VERSION cannot be empty here. Stop. > > Of course the "make sanity" without strace works perfectly. Conclusion: the Cygwin strace is buggy (big surprise) and can't be used to help peer "under the covers" of the hotspot make. > > > -----Original Message----- > From: Kelly Ohair [mailto:kelly.ohair at oracle.com] > Sent: Thursday, February 07, 2013 8:36 AM > To: Randy Nielsen > Cc: build-dev at openjdk.java.net > Subject: Re: Hang building JDK 7 Hotspot in Windows 7 > > no definite answers just ideas > > we are starting to use windows 2008R2 which seems better make sure the env vars TMP and TEMP are set to directories windows understands eg C:/ paths and these directories exist and have write permissions try using make LOG=debug,nofile > > > Sent from my iPhone > > On Feb 6, 2013, at 23:59, Randy Nielsen wrote: > >> I am thoroughly stuck building JDK 7 when I start the Hotspot portion of the build. This is Windows 7 64 bit building 64 bit JDK with Visual Studio 10 Service Pack 1. The hang seems to happen immediately after I start the hotspot portion of the make. There is no output at all. Watching the Windows Task Manager in the Processes tab shows the System Idle process at 99% almost all of the time. Occasionally mscorsvw.exe (.NET services) or minty.exe gets a few % of CPU but only very briefly. >> >>> From browsing the web I've tried the following "fixes": verified that there was no anti-virus program, and disabled ASLR (Address Space Layout Randomization). No change in behavior. >> Has anyone any ideas about how to deal with this? Also are there settings in the make that will dramatically increase the level of logging in the make that might help me debug this? >> >> Here's the output of the make hotspot: >> >> /usr/bin/mkdir -p >> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >> /usr/bin/mkdir -p >> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >> >> >> ###################################################################### >> ## >> ######################################################################## >> ##### Entering hotspot for target(s) all_product ##### >> ###################################################################### >> ## >> >> cd ./hotspot/make&& \ >> make JDK_TOPDIR=C:/OpenJDK/openjdk/jdk >> JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared >> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 >> JDK_BUILD_NUMBER=b00 >> FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 >> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 >> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 >> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 >> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 >> ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" >> ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >> ALT_EXPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >> ALT_SLASH_JAVA="c:/OpenJDK" ALT_BOOTDIR=c:/OpenJDK/jdk-6u18 >> ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/di >> st all_product >> >> ==>> That's it - no more output. >> >> The output of the sanity portion of the make is below. >> >> Hoping someone can help! >> >> Randy >> >> $ make >> cygwin warning: >> MS-DOS style path detected: C:/Windows/system32/wscript.exe >> Preferred POSIX equivalent is: >> /cygdrive/c/Windows/system32/wscript.exe >> CYGWIN environment variable option "nodosfilewarning" turns off this warning. >> Consult the user's guide for more details about POSIX paths: >> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames >> ( cd ./jdk/make&& \ >> make sanity HOTSPOT_IMPORT_CHECK=false >> JDK_TOPDIR=C:/OpenJDK/openjdk/jdk >> JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared >> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 >> JDK_BUILD_NUMBER=b00 >> FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 >> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 >> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 >> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 >> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 >> ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" >> ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64 >> ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/di >> st ALT_CORBA_DIST=C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >> ALT_JAXP_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >> ALT_JAXWS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >> ALT_HOTSPOT_IMPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot >> /import BUILD_HOTSPOT=true ; ) >> make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' >> make[1]: Leaving directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' >> >> Build Machine Information: >> build machine = WIN-R7HSHTAIIHC >> >> Build Directory Structure: >> CWD = /cygdrive/c/OpenJDK/openjdk >> TOPDIR = . >> LANGTOOLS_TOPDIR = ./langtools >> JAXP_TOPDIR = ./jaxp >> JAXWS_TOPDIR = ./jaxws >> CORBA_TOPDIR = ./corba >> HOTSPOT_TOPDIR = ./hotspot >> JDK_TOPDIR = ./jdk >> >> Build Directives: >> BUILD_LANGTOOLS = true >> BUILD_JAXP = true >> BUILD_JAXWS = true >> BUILD_CORBA = true >> BUILD_HOTSPOT = true >> BUILD_JDK = true >> DEBUG_CLASSFILES = >> DEBUG_BINARIES = >> >> Hotspot Settings: >> HOTSPOT_BUILD_JOBS = >> HOTSPOT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >> HOTSPOT_EXPORT_PATH = >> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >> >> >> >> >> Bootstrap Settings: >> BOOTDIR = c:/OpenJDK/jdk-6u18 >> ALT_BOOTDIR = c:/OpenJDK/jdk-6u18 >> BOOT_VER = 1.6.0 [requires at least 1.6] OUTPUTDIR = >> C:/OpenJDK/openjdk/build/windows-amd64 >> ALT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 >> ABS_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 >> >> Build Tool Settings: >> SLASH_JAVA = c:/OpenJDK >> ALT_SLASH_JAVA = c:/OpenJDK >> VARIANT = OPT >> JDK_DEVTOOLS_DIR = c:/OpenJDK/devtools >> ALT_JDK_DEVTOOLS_DIR = >> ANT_HOME = c:/OpenJDK/apache-ant-1.7.1 UNIXCOMMAND_PATH = /usr/bin/ >> ALT_UNIXCOMMAND_PATH = >> COMPILER_PATH = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/ >> ALT_COMPILER_PATH = >> DEVTOOLS_PATH = /usr/bin/ >> ALT_DEVTOOLS_PATH = >> MSVCRNN_DLL_PATH = C:/PROGRA~2/MICROS~2.0/Vc/redist/x64/Microsoft.VC100.CRT >> ALT_MSVCRNN_DLL_PATH = >> INCLUDE = >> C:/PROGRA~2/MICROS~2.0/VC/include;C:/MSSDKWIN7/Windows/v7.1/Include >> LIB = >> C:/PROGRA~2/MICROS~2.0/VC/lib/amd64;C:/MSSDKWIN7/Windows/v7.1/Lib/x64 >> COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) >> COMPILER_VERSION = VS2010 CC_VER = 16.00.40219.01 [requires at least >> 16.00.30319.01] ZIP_VER = 3.0 [requires at least 2.2] UNZIP_VER = >> 6.00 [requires at least 5.12] LINK_VER = 10.00.40219.01 [requires at >> least 10.00.30319.01] CC = >> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/cl >> LINK = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link >> DUMPBIN = >> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe >> ANT_VER = 1.7.1 [requires at least 1.7.1] TEMPDIR = >> C:/OpenJDK/openjdk/build/windows-amd64/tmp >> >> Build Directives: >> OPENJDK = true >> USE_HOTSPOT_INTERPRETER_MODE = >> PEDANTIC = >> DEV_ONLY = >> NO_DOCS = >> NO_IMAGES = >> TOOLS_ONLY = >> INSANE = >> COMPILE_APPROACH = normal >> FASTDEBUG = >> COMPILER_WARNINGS_FATAL = false >> COMPILER_WARNING_LEVEL = 3 >> SHOW_ALL_WARNINGS = false >> INCREMENTAL_BUILD = false >> CC_HIGHEST_OPT = >> CC_HIGHER_OPT = >> CC_LOWER_OPT = >> CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >> CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >> BOOT_JAVA_CMD = c:/OpenJDK/jdk-6u18/bin/java -XX:-PrintVMOptions >> -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m >> -XX:PermSize=32m -XX:MaxPermSize=160m BOOT_JAVAC_CMD = >> c:/OpenJDK/jdk-6u18/bin/javac -J-XX:ThreadStackSize=1536 >> -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions >> -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m >> -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 >> -XDignore.symbol.file=true BOOT_JAR_CMD = c:/OpenJDK/jdk-6u18/bin/jar >> BOOT_JARSIGNER_CMD = c:/OpenJDK/jdk-6u18/bin/jarsigner >> >> Build Platform Settings: >> USER = Administrator >> PLATFORM = windows >> ARCH = amd64 >> LIBARCH = amd64 >> ARCH_FAMILY = amd64 >> ARCH_DATA_MODEL = 64 >> ARCHPROP = amd64 >> PROCESSOR_ARCHITECTURE = x86 >> PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 26 Stepping 5, >> GenuineIntel USING_CYGWIN = true CYGWIN_VER = 6.1 [requires at least >> 4.0] CYGPATH_CMD = cygpath -a -s -m OS_VERSION = 6.1 [requires at >> least 5.2] OS_VARIANT_NAME = OS_VARIANT_VERSION = 6.1 MB_OF_MEMORY >> = 8191 >> >> GNU Make Settings: >> MAKE = make >> MAKE_VER = 3.82 [requires at least 3.81] MAKECMDGOALS = sanity >> MAKEFLAGS = w SHELL = /bin/sh >> >> Target Build Versions: >> JDK_VERSION = 1.7.0 >> MILESTONE = internal >> RELEASE = 1.7.0-internal >> FULL_VERSION = 1.7.0-internal-administrator_2013_02_06_23_32-b00 >> BUILD_NUMBER = b00 >> >> External File/Binary Locations: >> USRJDKINSTANCES_PATH = C:/PROGRA~1/Java BUILD_JDK_IMPORT_PATH = >> c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries >> ALT_BUILD_JDK_IMPORT_PATH = >> JDK_IMPORT_PATH = c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries/windows-amd64 >> ALT_JDK_IMPORT_PATH = >> LANGTOOLS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist >> ALT_LANGTOOLS_DIST = >> C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist >> CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >> ALT_CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >> JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >> ALT_JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >> JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >> ALT_JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >> HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR >> ALT_HOTSPOT_DOCS_IMPORT_PATH = >> HOTSPOT_IMPORT_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >> ALT_HOTSPOT_IMPORT_PATH = >> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >> HOTSPOT_SERVER_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/jre/bin/server >> ALT_HOTSPOT_SERVER_PATH = >> HOTSPOT_LIB_PATH = C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/lib >> ALT_HOTSPOT_LIB_PATH = >> DXSDK_VER = 0x0900 >> DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 >> ALT_DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 DXSDK_INCLUDE_PATH = >> C:/PROGRA~2/MI4ADD~1/Include >> ALT_DXSDK_INCLUDE_PATH = >> DXSDK_LIB_PATH = C:/PROGRA~2/MI4ADD~1/Lib/x64 >> ALT_DXSDK_LIB_PATH = >> WINDOWSSDKDIR = C:/PROGRA~2/MICROS~1/Windows/v7.0a/ >> ALT_WINDOWSSDKDIR = >> RC = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/RC.Exe >> REBASE = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/ReBase.Exe >> CACERTS_FILE = ./../src/share/lib/security/cacerts >> ALT_CACERTS_FILE = >> >> OpenJDK-specific settings: >> FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include >> ALT_FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include >> FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 >> ALT_FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 >> >> Previous JDK Settings: >> PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE >> ALT_PREVIOUS_RELEASE_PATH = >> PREVIOUS_JDK_VERSION = 1.6.0 >> ALT_PREVIOUS_JDK_VERSION = >> PREVIOUS_JDK_FILE = >> ALT_PREVIOUS_JDK_FILE = >> PREVIOUS_JRE_FILE = >> ALT_PREVIOUS_JRE_FILE = >> PREVIOUS_RELEASE_IMAGE = c:/OpenJDK/jdk-6u18 >> ALT_PREVIOUS_RELEASE_IMAGE = >> >> >> WARNING: To build Java 2 SDK 1.7.0 you need : >> VS2010 - link.exe version '10.00.30319.01' >> Specifically the Visual Studio 10 link.exe. >> You appear to be using Linker version '10.00.40219.01' >> >> Sanity check passed. >> make \ >> SKIP_FASTDEBUG_BUILD=true \ >> SKIP_DEBUG_BUILD=true \ >> \ >> generic_build_repo_series >> make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk' >> /usr/bin/mkdir -p ./build/windows-amd64/j2sdk-image /usr/bin/mkdir -p >> C:/OpenJDK/openjdk/build/windows-amd64/langtools >> >> == End of listing of make sanity portion of build == >> >> From alexandr.scherbatiy at oracle.com Fri Feb 8 12:18:14 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 08 Feb 2013 16:18:14 +0400 Subject: OpenJDK rebuilding on windows takes a long time Message-ID: <5114ED06.1040802@oracle.com> Building one line change in OpenJDK on my Windows takes about from 4 to 7 minutes. I tried to install the ccache-3.1.9 but build process fails with error: ------------------------------------------------- LINK : fatal error LNK1181: cannot open input file 'c:/Sun/OpenJDK/jdk8-awt/build/windows-x86-normal-server-release/jdk/objs/libverify/check_code.obj' LINK : fatal error LNK1181: cannot open input file 'c:/Sun/OpenJDK/jdk8-awt/build/windows-x86-normal-server-release/jdk/objs/libfdlibm/e_acos.obj' LINK : fatal error LNK1181: cannot open input file 'c:/Sun/OpenJDK/jdk8-awt/build/windows-x86-normal-server-release/jdk/objs/libdt_shmem/SharedMemoryConnection.obj' Could not start process! Failed with error 2: ?? ??????? ????? ????????? ????. make[2]: *** [/cygdrive/c/Sun/OpenJDK/jdk8-awt/build/windows-x86-normal-server-release/jdk/objs/fdlibm.lib] Error 157 make[2]: *** Waiting for unfinished jobs.... make[2]: *** [/cygdrive/c/Sun/OpenJDK/jdk8-awt/build/windows-x86-normal-server-release/jdk/bin/verify.dll] Error 157 make[2]: *** [/cygdrive/c/Sun/OpenJDK/jdk8-awt/build/windows-x86-normal-server-release/jdk/bin/dt_shmem.dll] Error 157 make[1]: *** [libs-only] Error 2 make: *** [jdk-only] Error 2 ------------------------------------------------- 7 minutes is too long for the small change rebuilding. The previous systems makes it faster. Is it possible to use the ccache on windows or make the rebuilding process faster? Thanks, Alexandr. From erik.joelsson at oracle.com Fri Feb 8 14:46:11 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 08 Feb 2013 15:46:11 +0100 Subject: OpenJDK rebuilding on windows takes a long time In-Reply-To: <5114ED06.1040802@oracle.com> References: <5114ED06.1040802@oracle.com> Message-ID: <51150FB3.7@oracle.com> Ccache is not supported on windows since it doesn't work with visual studio AFAIK. What kind of change did you do? Was it in native code or java and in which repository? /Erik On 2013-02-08 13:18, Alexander Scherbatiy wrote: > > Building one line change in OpenJDK on my Windows takes about from 4 > to 7 minutes. > > I tried to install the ccache-3.1.9 but build process fails with error: > ------------------------------------------------- > LINK : fatal error LNK1181: cannot open input file > 'c:/Sun/OpenJDK/jdk8-awt/build/windows-x86-normal-server-release/jdk/objs/libverify/check_code.obj' > LINK : fatal error LNK1181: cannot open input file > 'c:/Sun/OpenJDK/jdk8-awt/build/windows-x86-normal-server-release/jdk/objs/libfdlibm/e_acos.obj' > LINK : fatal error LNK1181: cannot open input file > 'c:/Sun/OpenJDK/jdk8-awt/build/windows-x86-normal-server-release/jdk/objs/libdt_shmem/SharedMemoryConnection.obj' > > Could not start process! Failed with error 2: ?? ??????? ????? > ????????? ????. > > make[2]: *** > [/cygdrive/c/Sun/OpenJDK/jdk8-awt/build/windows-x86-normal-server-release/jdk/objs/fdlibm.lib] > Error 157 > make[2]: *** Waiting for unfinished jobs.... > make[2]: *** > [/cygdrive/c/Sun/OpenJDK/jdk8-awt/build/windows-x86-normal-server-release/jdk/bin/verify.dll] > Error 157 > make[2]: *** > [/cygdrive/c/Sun/OpenJDK/jdk8-awt/build/windows-x86-normal-server-release/jdk/bin/dt_shmem.dll] > Error 157 > make[1]: *** [libs-only] Error 2 > make: *** [jdk-only] Error 2 > ------------------------------------------------- > > 7 minutes is too long for the small change rebuilding. The previous > systems makes it faster. > Is it possible to use the ccache on windows or make the rebuilding > process faster? > > Thanks, > Alexandr. > > From tim.bell at oracle.com Fri Feb 8 15:08:20 2013 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 08 Feb 2013 07:08:20 -0800 Subject: Hang building JDK 7 Hotspot in Windows 7 In-Reply-To: <5114ACA5.7080908@oracle.com> References: <1AC3281AD57A34468B9879C754022CAF05F1497130@exchange.vocera.local> <29D2F8E5-D2E7-441F-86C7-63888F114A8F@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F14975BE@exchange.vocera.local> <5114ACA5.7080908@oracle.com> Message-ID: <511514E4.2070108@oracle.com> For the hotspot build, 'gmake MAKE_VERBOSE=y' or 'gmake QUIETLY=' gives more details. You need 'nmake' on your PATH when building in hotspot. Also, verify that the VS2010 'link' is on PATH _before_ the Cygwin link.exe. http://hg.openjdk.java.net/jdk7u/jdk7u/raw-file/7ffd73535b8e/README-builds.html#msvc32 Hope this helps- Tim On 02/07/13 23:43, Erik Joelsson wrote: > The LOG=debug is JDK8 and build-infra specific. For JDK7 I don't know > of a way to get more info except adding the -d or --debug flag to > make, which as David says is rather useless most of the time. > > /Erik > > On 2013-02-08 00:47, Randy Nielsen wrote: >> Tried suggestions with no change. Specifically LOG=debug,nofile >> didn't add any output at all. Are there any others ways to poke the >> make to get more output, say a line by line trace of the make >> behavior? This feels like a process synchronization problem where >> process A is waiting to be notified by someone and of course the >> notify never occurs. But why would a bunch of compiles etc. use this >> kind of synchronization? >> >> Also I tried strace to peek under the covers, and concluded that >> Cygwin strace is very buggy. Details (optional) follow, after my >> signature. >> >> Randy >> >> I ran strace on top of the make of hotspot and to my utter >> astonishment after a few seconds it ended like this: >> >> $ strace make hotspot>strace.txt >> /bin/sh: >> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link: >> Function not implemented >> jdk/make/common/shared/Compiler-msvc.gmk:80: *** COMPILER_VERSION >> cannot be empty here. Stop. >> >> Being a suspicious soul I then tried this: >> >> $ strace make sanity>trace.txt >> /bin/sh: >> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link: >> Function not implemented >> jdk/make/common/shared/Compiler-msvc.gmk:80: *** COMPILER_VERSION >> cannot be empty here. Stop. >> >> Of course the "make sanity" without strace works perfectly. >> Conclusion: the Cygwin strace is buggy (big surprise) and can't be >> used to help peer "under the covers" of the hotspot make. >> >> >> -----Original Message----- >> From: Kelly Ohair [mailto:kelly.ohair at oracle.com] >> Sent: Thursday, February 07, 2013 8:36 AM >> To: Randy Nielsen >> Cc: build-dev at openjdk.java.net >> Subject: Re: Hang building JDK 7 Hotspot in Windows 7 >> >> no definite answers just ideas >> >> we are starting to use windows 2008R2 which seems better make sure >> the env vars TMP and TEMP are set to directories windows understands >> eg C:/ paths and these directories exist and have write permissions >> try using make LOG=debug,nofile >> >> >> Sent from my iPhone >> >> On Feb 6, 2013, at 23:59, Randy Nielsen wrote: >> >>> I am thoroughly stuck building JDK 7 when I start the Hotspot >>> portion of the build. This is Windows 7 64 bit building 64 bit JDK >>> with Visual Studio 10 Service Pack 1. The hang seems to happen >>> immediately after I start the hotspot portion of the make. There is >>> no output at all. Watching the Windows Task Manager in the >>> Processes tab shows the System Idle process at 99% almost all of the >>> time. Occasionally mscorsvw.exe (.NET services) or minty.exe gets a >>> few % of CPU but only very briefly. >>> >>>> From browsing the web I've tried the following "fixes": verified >>>> that there was no anti-virus program, and disabled ASLR (Address >>>> Space Layout Randomization). No change in behavior. >>> Has anyone any ideas about how to deal with this? Also are there >>> settings in the make that will dramatically increase the level of >>> logging in the make that might help me debug this? >>> >>> Here's the output of the make hotspot: >>> >>> /usr/bin/mkdir -p >>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >>> /usr/bin/mkdir -p >>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>> >>> >>> ###################################################################### >>> ## >>> ######################################################################## >>> >>> ##### Entering hotspot for target(s) all_product >>> ##### >>> ###################################################################### >>> ## >>> >>> cd ./hotspot/make&& \ >>> make JDK_TOPDIR=C:/OpenJDK/openjdk/jdk >>> JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared >>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 >>> JDK_BUILD_NUMBER=b00 >>> FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 >>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 >>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 >>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 >>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 >>> ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" >>> ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >>> ALT_EXPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>> ALT_SLASH_JAVA="c:/OpenJDK" ALT_BOOTDIR=c:/OpenJDK/jdk-6u18 >>> ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/di >>> st all_product >>> >>> ==>> That's it - no more output. >>> >>> The output of the sanity portion of the make is below. >>> >>> Hoping someone can help! >>> >>> Randy >>> >>> $ make >>> cygwin warning: >>> MS-DOS style path detected: C:/Windows/system32/wscript.exe >>> Preferred POSIX equivalent is: >>> /cygdrive/c/Windows/system32/wscript.exe >>> CYGWIN environment variable option "nodosfilewarning" turns off >>> this warning. >>> Consult the user's guide for more details about POSIX paths: >>> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames >>> ( cd ./jdk/make&& \ >>> make sanity HOTSPOT_IMPORT_CHECK=false >>> JDK_TOPDIR=C:/OpenJDK/openjdk/jdk >>> JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared >>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 >>> JDK_BUILD_NUMBER=b00 >>> FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 >>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 >>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 >>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 >>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 >>> ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" >>> ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64 >>> ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/di >>> st ALT_CORBA_DIST=C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >>> ALT_JAXP_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >>> ALT_JAXWS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >>> ALT_HOTSPOT_IMPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot >>> /import BUILD_HOTSPOT=true ; ) >>> make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' >>> make[1]: Leaving directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' >>> >>> Build Machine Information: >>> build machine = WIN-R7HSHTAIIHC >>> >>> Build Directory Structure: >>> CWD = /cygdrive/c/OpenJDK/openjdk >>> TOPDIR = . >>> LANGTOOLS_TOPDIR = ./langtools >>> JAXP_TOPDIR = ./jaxp >>> JAXWS_TOPDIR = ./jaxws >>> CORBA_TOPDIR = ./corba >>> HOTSPOT_TOPDIR = ./hotspot >>> JDK_TOPDIR = ./jdk >>> >>> Build Directives: >>> BUILD_LANGTOOLS = true >>> BUILD_JAXP = true >>> BUILD_JAXWS = true >>> BUILD_CORBA = true >>> BUILD_HOTSPOT = true >>> BUILD_JDK = true >>> DEBUG_CLASSFILES = >>> DEBUG_BINARIES = >>> >>> Hotspot Settings: >>> HOTSPOT_BUILD_JOBS = >>> HOTSPOT_OUTPUTDIR = >>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >>> HOTSPOT_EXPORT_PATH = >>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>> >>> >>> >>> >>> Bootstrap Settings: >>> BOOTDIR = c:/OpenJDK/jdk-6u18 >>> ALT_BOOTDIR = c:/OpenJDK/jdk-6u18 >>> BOOT_VER = 1.6.0 [requires at least 1.6] OUTPUTDIR = >>> C:/OpenJDK/openjdk/build/windows-amd64 >>> ALT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 >>> ABS_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 >>> >>> Build Tool Settings: >>> SLASH_JAVA = c:/OpenJDK >>> ALT_SLASH_JAVA = c:/OpenJDK >>> VARIANT = OPT >>> JDK_DEVTOOLS_DIR = c:/OpenJDK/devtools >>> ALT_JDK_DEVTOOLS_DIR = >>> ANT_HOME = c:/OpenJDK/apache-ant-1.7.1 UNIXCOMMAND_PATH = /usr/bin/ >>> ALT_UNIXCOMMAND_PATH = >>> COMPILER_PATH = >>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/ >>> ALT_COMPILER_PATH = >>> DEVTOOLS_PATH = /usr/bin/ >>> ALT_DEVTOOLS_PATH = >>> MSVCRNN_DLL_PATH = >>> C:/PROGRA~2/MICROS~2.0/Vc/redist/x64/Microsoft.VC100.CRT >>> ALT_MSVCRNN_DLL_PATH = >>> INCLUDE = >>> C:/PROGRA~2/MICROS~2.0/VC/include;C:/MSSDKWIN7/Windows/v7.1/Include >>> LIB = >>> C:/PROGRA~2/MICROS~2.0/VC/lib/amd64;C:/MSSDKWIN7/Windows/v7.1/Lib/x64 >>> COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) >>> COMPILER_VERSION = VS2010 CC_VER = 16.00.40219.01 [requires at least >>> 16.00.30319.01] ZIP_VER = 3.0 [requires at least 2.2] UNZIP_VER = >>> 6.00 [requires at least 5.12] LINK_VER = 10.00.40219.01 [requires at >>> least 10.00.30319.01] CC = >>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/cl >>> LINK = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link >>> DUMPBIN = >>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe >>> ANT_VER = 1.7.1 [requires at least 1.7.1] TEMPDIR = >>> C:/OpenJDK/openjdk/build/windows-amd64/tmp >>> >>> Build Directives: >>> OPENJDK = true >>> USE_HOTSPOT_INTERPRETER_MODE = >>> PEDANTIC = >>> DEV_ONLY = >>> NO_DOCS = >>> NO_IMAGES = >>> TOOLS_ONLY = >>> INSANE = >>> COMPILE_APPROACH = normal >>> FASTDEBUG = >>> COMPILER_WARNINGS_FATAL = false >>> COMPILER_WARNING_LEVEL = 3 >>> SHOW_ALL_WARNINGS = false >>> INCREMENTAL_BUILD = false >>> CC_HIGHEST_OPT = >>> CC_HIGHER_OPT = >>> CC_LOWER_OPT = >>> CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D >>> _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- >>> -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb >>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 >>> -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >>> CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D >>> _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- >>> -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb >>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 >>> -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >>> BOOT_JAVA_CMD = c:/OpenJDK/jdk-6u18/bin/java -XX:-PrintVMOptions >>> -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m >>> -XX:PermSize=32m -XX:MaxPermSize=160m BOOT_JAVAC_CMD = >>> c:/OpenJDK/jdk-6u18/bin/javac -J-XX:ThreadStackSize=1536 >>> -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions >>> -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m >>> -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 >>> -XDignore.symbol.file=true BOOT_JAR_CMD = c:/OpenJDK/jdk-6u18/bin/jar >>> BOOT_JARSIGNER_CMD = c:/OpenJDK/jdk-6u18/bin/jarsigner >>> >>> Build Platform Settings: >>> USER = Administrator >>> PLATFORM = windows >>> ARCH = amd64 >>> LIBARCH = amd64 >>> ARCH_FAMILY = amd64 >>> ARCH_DATA_MODEL = 64 >>> ARCHPROP = amd64 >>> PROCESSOR_ARCHITECTURE = x86 >>> PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 26 Stepping 5, >>> GenuineIntel USING_CYGWIN = true CYGWIN_VER = 6.1 [requires at least >>> 4.0] CYGPATH_CMD = cygpath -a -s -m OS_VERSION = 6.1 [requires at >>> least 5.2] OS_VARIANT_NAME = OS_VARIANT_VERSION = 6.1 MB_OF_MEMORY >>> = 8191 >>> >>> GNU Make Settings: >>> MAKE = make >>> MAKE_VER = 3.82 [requires at least 3.81] MAKECMDGOALS = sanity >>> MAKEFLAGS = w SHELL = /bin/sh >>> >>> Target Build Versions: >>> JDK_VERSION = 1.7.0 >>> MILESTONE = internal >>> RELEASE = 1.7.0-internal >>> FULL_VERSION = 1.7.0-internal-administrator_2013_02_06_23_32-b00 >>> BUILD_NUMBER = b00 >>> >>> External File/Binary Locations: >>> USRJDKINSTANCES_PATH = C:/PROGRA~1/Java BUILD_JDK_IMPORT_PATH = >>> c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries >>> ALT_BUILD_JDK_IMPORT_PATH = >>> JDK_IMPORT_PATH = >>> c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries/windows-amd64 >>> ALT_JDK_IMPORT_PATH = >>> LANGTOOLS_DIST = >>> C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist >>> ALT_LANGTOOLS_DIST = >>> C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist >>> CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >>> ALT_CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >>> JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >>> ALT_JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >>> JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >>> ALT_JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >>> HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR >>> ALT_HOTSPOT_DOCS_IMPORT_PATH = >>> HOTSPOT_IMPORT_PATH = >>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>> ALT_HOTSPOT_IMPORT_PATH = >>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>> HOTSPOT_SERVER_PATH = >>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/jre/bin/server >>> ALT_HOTSPOT_SERVER_PATH = >>> HOTSPOT_LIB_PATH = >>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/lib >>> ALT_HOTSPOT_LIB_PATH = >>> DXSDK_VER = 0x0900 >>> DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 >>> ALT_DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 DXSDK_INCLUDE_PATH = >>> C:/PROGRA~2/MI4ADD~1/Include >>> ALT_DXSDK_INCLUDE_PATH = >>> DXSDK_LIB_PATH = C:/PROGRA~2/MI4ADD~1/Lib/x64 >>> ALT_DXSDK_LIB_PATH = >>> WINDOWSSDKDIR = C:/PROGRA~2/MICROS~1/Windows/v7.0a/ >>> ALT_WINDOWSSDKDIR = >>> RC = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/RC.Exe >>> REBASE = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/ReBase.Exe >>> CACERTS_FILE = ./../src/share/lib/security/cacerts >>> ALT_CACERTS_FILE = >>> >>> OpenJDK-specific settings: >>> FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include >>> ALT_FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include >>> FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 >>> ALT_FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 >>> >>> Previous JDK Settings: >>> PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE >>> ALT_PREVIOUS_RELEASE_PATH = >>> PREVIOUS_JDK_VERSION = 1.6.0 >>> ALT_PREVIOUS_JDK_VERSION = >>> PREVIOUS_JDK_FILE = >>> ALT_PREVIOUS_JDK_FILE = >>> PREVIOUS_JRE_FILE = >>> ALT_PREVIOUS_JRE_FILE = >>> PREVIOUS_RELEASE_IMAGE = c:/OpenJDK/jdk-6u18 >>> ALT_PREVIOUS_RELEASE_IMAGE = >>> >>> >>> WARNING: To build Java 2 SDK 1.7.0 you need : >>> VS2010 - link.exe version '10.00.30319.01' >>> Specifically the Visual Studio 10 link.exe. >>> You appear to be using Linker version '10.00.40219.01' >>> >>> Sanity check passed. >>> make \ >>> SKIP_FASTDEBUG_BUILD=true \ >>> SKIP_DEBUG_BUILD=true \ >>> \ >>> generic_build_repo_series >>> make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk' >>> /usr/bin/mkdir -p ./build/windows-amd64/j2sdk-image /usr/bin/mkdir -p >>> C:/OpenJDK/openjdk/build/windows-amd64/langtools >>> >>> == End of listing of make sanity portion of build == >>> >>> From mikael.vidstedt at oracle.com Fri Feb 8 18:30:04 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 08 Feb 2013 10:30:04 -0800 Subject: RFR (S): 8007639: Workaround for ccache in vm.make is incorrect Message-ID: <5115442C.5030309@oracle.com> Please review the following change: Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.00/webrev Bug: http://bugs.sun.com/view_bug.do?bug_id=8007639 This change corrects the workaround that was introduced in vm.make for enabling ccache for HotSpot builds. The change introduces a file specific makefile variable (CFLAGS/) which is used to only set the JRE_RELEASE_VERSION define when compiling vm_version.o. Verified manually by observing command lines with/without fix, also passes JPRT. Some additional background below, more information is available in the bug report: To enable the use of ccache 7132779 [1] introduced some new makefile logic in vm.make to only pass the JRE_RELEASE_VERSION define when compiling the vm_version.cpp file. The underlying reason for that is that the JRE_RELEASE_VERSION can in some cases contain a time stamp and since ccache checks that the defines match before reusing the cache version of the object file that would mean that if the time stamp changed all files would have to be recompiled. With the fix only vm_version.cpp needs to be recompiled. This almost works, but the logic introduced in the makefile is actually incorrect. Today it looks like this: # This is VERY important! The version define must only be supplied to vm_version.o # If not, ccache will not re-use the cache at all, since the version string might contain # a time and date. vm_version.o: CXXFLAGS += ${JRE_VERSION} However, the above syntax does not only add the ${JRE_VERSION} to the CXXFLAGS of vm_version.o as originally intended - it also /in some cases/ adds it to the CXXFLAGS for any and all prerequisites of vm_version.o. And vm_version.o depends on all other object files, which means in theory this actually passes in that potentially time stamped version string define to all object files anyway. For various reasons in reality it only passes it to files that are lexicographically after vm_version.o - see bug report for more background on why - but there's still a handful of files that will be recompiled unnecessarily. Cheers, Mikael [1] http://bugs.sun.com/view_bug.do?bug_id=7132779 From volker.simonis at gmail.com Fri Feb 8 18:44:36 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 8 Feb 2013 19:44:36 +0100 Subject: Hang building JDK 7 Hotspot in Windows 7 In-Reply-To: <511514E4.2070108@oracle.com> References: <1AC3281AD57A34468B9879C754022CAF05F1497130@exchange.vocera.local> <29D2F8E5-D2E7-441F-86C7-63888F114A8F@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F14975BE@exchange.vocera.local> <5114ACA5.7080908@oracle.com> <511514E4.2070108@oracle.com> Message-ID: Sorry to say this, but I think this is a problem of new Cygwin versions. I've just tried with the newest 1.7.17 (see "uname -r") under Windows Server 2003 and it hangs as well. I really think that all has been already said about this topic, see: http://openjdk.5641.n7.nabble.com/Is-anyone-able-to-build-on-Win-7-td81697.html#a33196055 http://weblogs.java.net/blog/simonis/archive/2011/10/28/yaojowbi-yet-another-openjdk-windows-build-instruction If nobody will be able to provide a complete Cygwin version 1.7.9 or older (actually, that's my best guess:) I think we will be out of luck. I've tried the whole afternoon to download such a version without success. If somebody else succeeds, PLEASE, PLEASE make it available somewhere for download otherwise I don't see how anybody else will ever be able to build OpenJDK 7 on Windows except on machines which have been set up years ago. The only alternatives are: - use MKS ($$$$) - use the new build system (currently only for JDK8) - use MinGW/MSYS (not sure what the current status of MinGW/MSYS support is in JDK7 because I've submitted these changes about a year ago. I think most of them have been integrated, but mostly to the jdk8 repositories (see http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html which contains some hints for MinGW/MSYS builds). As far as I can see they are not in the jdk7 README (http://hg.openjdk.java.net/jdk7u/jdk7u/raw-file/tip/README-builds.html) so the build file changes may still have to be back-ported ) . Regards, Volker On Fri, Feb 8, 2013 at 4:08 PM, Tim Bell wrote: > For the hotspot build, 'gmake MAKE_VERBOSE=y' or 'gmake QUIETLY=' gives more > details. > > You need 'nmake' on your PATH when building in hotspot. > > Also, verify that the VS2010 'link' is on PATH _before_ the Cygwin link.exe. > > http://hg.openjdk.java.net/jdk7u/jdk7u/raw-file/7ffd73535b8e/README-builds.html#msvc32 > > > Hope this helps- > > Tim > > > On 02/07/13 23:43, Erik Joelsson wrote: >> >> The LOG=debug is JDK8 and build-infra specific. For JDK7 I don't know of a >> way to get more info except adding the -d or --debug flag to make, which as >> David says is rather useless most of the time. >> >> /Erik >> >> On 2013-02-08 00:47, Randy Nielsen wrote: >>> >>> Tried suggestions with no change. Specifically LOG=debug,nofile didn't >>> add any output at all. Are there any others ways to poke the make to get >>> more output, say a line by line trace of the make behavior? This feels like >>> a process synchronization problem where process A is waiting to be notified >>> by someone and of course the notify never occurs. But why would a bunch of >>> compiles etc. use this kind of synchronization? >>> >>> Also I tried strace to peek under the covers, and concluded that Cygwin >>> strace is very buggy. Details (optional) follow, after my signature. >>> >>> Randy >>> >>> I ran strace on top of the make of hotspot and to my utter astonishment >>> after a few seconds it ended like this: >>> >>> $ strace make hotspot>strace.txt >>> /bin/sh: >>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link: Function not >>> implemented >>> jdk/make/common/shared/Compiler-msvc.gmk:80: *** COMPILER_VERSION >>> cannot be empty here. Stop. >>> >>> Being a suspicious soul I then tried this: >>> >>> $ strace make sanity>trace.txt >>> /bin/sh: >>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link: Function not >>> implemented >>> jdk/make/common/shared/Compiler-msvc.gmk:80: *** COMPILER_VERSION >>> cannot be empty here. Stop. >>> >>> Of course the "make sanity" without strace works perfectly. Conclusion: >>> the Cygwin strace is buggy (big surprise) and can't be used to help peer >>> "under the covers" of the hotspot make. >>> >>> >>> -----Original Message----- >>> From: Kelly Ohair [mailto:kelly.ohair at oracle.com] >>> Sent: Thursday, February 07, 2013 8:36 AM >>> To: Randy Nielsen >>> Cc: build-dev at openjdk.java.net >>> Subject: Re: Hang building JDK 7 Hotspot in Windows 7 >>> >>> no definite answers just ideas >>> >>> we are starting to use windows 2008R2 which seems better make sure the >>> env vars TMP and TEMP are set to directories windows understands eg C:/ >>> paths and these directories exist and have write permissions try using make >>> LOG=debug,nofile >>> >>> >>> Sent from my iPhone >>> >>> On Feb 6, 2013, at 23:59, Randy Nielsen wrote: >>> >>>> I am thoroughly stuck building JDK 7 when I start the Hotspot portion of >>>> the build. This is Windows 7 64 bit building 64 bit JDK with Visual Studio >>>> 10 Service Pack 1. The hang seems to happen immediately after I start the >>>> hotspot portion of the make. There is no output at all. Watching the >>>> Windows Task Manager in the Processes tab shows the System Idle process at >>>> 99% almost all of the time. Occasionally mscorsvw.exe (.NET services) or >>>> minty.exe gets a few % of CPU but only very briefly. >>>> >>>>> From browsing the web I've tried the following "fixes": verified that >>>>> there was no anti-virus program, and disabled ASLR (Address Space Layout >>>>> Randomization). No change in behavior. >>>> >>>> Has anyone any ideas about how to deal with this? Also are there >>>> settings in the make that will dramatically increase the level of logging in >>>> the make that might help me debug this? >>>> >>>> Here's the output of the make hotspot: >>>> >>>> /usr/bin/mkdir -p >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >>>> /usr/bin/mkdir -p >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>>> >>>> >>>> ###################################################################### >>>> ## >>>> ######################################################################## >>>> ##### Entering hotspot for target(s) all_product ##### >>>> ###################################################################### >>>> ## >>>> >>>> cd ./hotspot/make&& \ >>>> make JDK_TOPDIR=C:/OpenJDK/openjdk/jdk >>>> JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared >>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >>>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 >>>> JDK_BUILD_NUMBER=b00 >>>> FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 >>>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 >>>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 >>>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 >>>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 >>>> ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" >>>> ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >>>> ALT_EXPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>>> ALT_SLASH_JAVA="c:/OpenJDK" ALT_BOOTDIR=c:/OpenJDK/jdk-6u18 >>>> ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/di >>>> st all_product >>>> >>>> ==>> That's it - no more output. >>>> >>>> The output of the sanity portion of the make is below. >>>> >>>> Hoping someone can help! >>>> >>>> Randy >>>> >>>> $ make >>>> cygwin warning: >>>> MS-DOS style path detected: C:/Windows/system32/wscript.exe >>>> Preferred POSIX equivalent is: >>>> /cygdrive/c/Windows/system32/wscript.exe >>>> CYGWIN environment variable option "nodosfilewarning" turns off this >>>> warning. >>>> Consult the user's guide for more details about POSIX paths: >>>> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames >>>> ( cd ./jdk/make&& \ >>>> make sanity HOTSPOT_IMPORT_CHECK=false >>>> JDK_TOPDIR=C:/OpenJDK/openjdk/jdk >>>> JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared >>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >>>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 >>>> JDK_BUILD_NUMBER=b00 >>>> FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 >>>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 >>>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 >>>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 >>>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 >>>> ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" >>>> ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64 >>>> ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools/di >>>> st ALT_CORBA_DIST=C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >>>> ALT_JAXP_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >>>> ALT_JAXWS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >>>> ALT_HOTSPOT_IMPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot >>>> /import BUILD_HOTSPOT=true ; ) >>>> make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' >>>> make[1]: Leaving directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' >>>> >>>> Build Machine Information: >>>> build machine = WIN-R7HSHTAIIHC >>>> >>>> Build Directory Structure: >>>> CWD = /cygdrive/c/OpenJDK/openjdk >>>> TOPDIR = . >>>> LANGTOOLS_TOPDIR = ./langtools >>>> JAXP_TOPDIR = ./jaxp >>>> JAXWS_TOPDIR = ./jaxws >>>> CORBA_TOPDIR = ./corba >>>> HOTSPOT_TOPDIR = ./hotspot >>>> JDK_TOPDIR = ./jdk >>>> >>>> Build Directives: >>>> BUILD_LANGTOOLS = true >>>> BUILD_JAXP = true >>>> BUILD_JAXWS = true >>>> BUILD_CORBA = true >>>> BUILD_HOTSPOT = true >>>> BUILD_JDK = true >>>> DEBUG_CLASSFILES = >>>> DEBUG_BINARIES = >>>> >>>> Hotspot Settings: >>>> HOTSPOT_BUILD_JOBS = >>>> HOTSPOT_OUTPUTDIR = >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >>>> HOTSPOT_EXPORT_PATH = >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>>> >>>> >>>> >>>> >>>> Bootstrap Settings: >>>> BOOTDIR = c:/OpenJDK/jdk-6u18 >>>> ALT_BOOTDIR = c:/OpenJDK/jdk-6u18 >>>> BOOT_VER = 1.6.0 [requires at least 1.6] OUTPUTDIR = >>>> C:/OpenJDK/openjdk/build/windows-amd64 >>>> ALT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 >>>> ABS_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 >>>> >>>> Build Tool Settings: >>>> SLASH_JAVA = c:/OpenJDK >>>> ALT_SLASH_JAVA = c:/OpenJDK >>>> VARIANT = OPT >>>> JDK_DEVTOOLS_DIR = c:/OpenJDK/devtools >>>> ALT_JDK_DEVTOOLS_DIR = >>>> ANT_HOME = c:/OpenJDK/apache-ant-1.7.1 UNIXCOMMAND_PATH = /usr/bin/ >>>> ALT_UNIXCOMMAND_PATH = >>>> COMPILER_PATH = >>>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/ >>>> ALT_COMPILER_PATH = >>>> DEVTOOLS_PATH = /usr/bin/ >>>> ALT_DEVTOOLS_PATH = >>>> MSVCRNN_DLL_PATH = >>>> C:/PROGRA~2/MICROS~2.0/Vc/redist/x64/Microsoft.VC100.CRT >>>> ALT_MSVCRNN_DLL_PATH = >>>> INCLUDE = >>>> C:/PROGRA~2/MICROS~2.0/VC/include;C:/MSSDKWIN7/Windows/v7.1/Include >>>> LIB = >>>> C:/PROGRA~2/MICROS~2.0/VC/lib/amd64;C:/MSSDKWIN7/Windows/v7.1/Lib/x64 >>>> COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) >>>> COMPILER_VERSION = VS2010 CC_VER = 16.00.40219.01 [requires at least >>>> 16.00.30319.01] ZIP_VER = 3.0 [requires at least 2.2] UNZIP_VER = >>>> 6.00 [requires at least 5.12] LINK_VER = 10.00.40219.01 [requires at >>>> least 10.00.30319.01] CC = >>>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/cl >>>> LINK = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link >>>> DUMPBIN = >>>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe >>>> ANT_VER = 1.7.1 [requires at least 1.7.1] TEMPDIR = >>>> C:/OpenJDK/openjdk/build/windows-amd64/tmp >>>> >>>> Build Directives: >>>> OPENJDK = true >>>> USE_HOTSPOT_INTERPRETER_MODE = >>>> PEDANTIC = >>>> DEV_ONLY = >>>> NO_DOCS = >>>> NO_IMAGES = >>>> TOOLS_ONLY = >>>> INSANE = >>>> COMPILE_APPROACH = normal >>>> FASTDEBUG = >>>> COMPILER_WARNINGS_FATAL = false >>>> COMPILER_WARNING_LEVEL = 3 >>>> SHOW_ALL_WARNINGS = false >>>> INCREMENTAL_BUILD = false >>>> CC_HIGHEST_OPT = >>>> CC_HIGHER_OPT = >>>> CC_LOWER_OPT = >>>> CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D >>>> _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- >>>> -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb >>>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D >>>> _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >>>> CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D >>>> _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- >>>> -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb >>>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 -W3 -D >>>> _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >>>> BOOT_JAVA_CMD = c:/OpenJDK/jdk-6u18/bin/java -XX:-PrintVMOptions >>>> -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m >>>> -XX:PermSize=32m -XX:MaxPermSize=160m BOOT_JAVAC_CMD = >>>> c:/OpenJDK/jdk-6u18/bin/javac -J-XX:ThreadStackSize=1536 >>>> -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions >>>> -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m >>>> -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 >>>> -XDignore.symbol.file=true BOOT_JAR_CMD = c:/OpenJDK/jdk-6u18/bin/jar >>>> BOOT_JARSIGNER_CMD = c:/OpenJDK/jdk-6u18/bin/jarsigner >>>> >>>> Build Platform Settings: >>>> USER = Administrator >>>> PLATFORM = windows >>>> ARCH = amd64 >>>> LIBARCH = amd64 >>>> ARCH_FAMILY = amd64 >>>> ARCH_DATA_MODEL = 64 >>>> ARCHPROP = amd64 >>>> PROCESSOR_ARCHITECTURE = x86 >>>> PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 26 Stepping 5, >>>> GenuineIntel USING_CYGWIN = true CYGWIN_VER = 6.1 [requires at least >>>> 4.0] CYGPATH_CMD = cygpath -a -s -m OS_VERSION = 6.1 [requires at >>>> least 5.2] OS_VARIANT_NAME = OS_VARIANT_VERSION = 6.1 MB_OF_MEMORY >>>> = 8191 >>>> >>>> GNU Make Settings: >>>> MAKE = make >>>> MAKE_VER = 3.82 [requires at least 3.81] MAKECMDGOALS = sanity >>>> MAKEFLAGS = w SHELL = /bin/sh >>>> >>>> Target Build Versions: >>>> JDK_VERSION = 1.7.0 >>>> MILESTONE = internal >>>> RELEASE = 1.7.0-internal >>>> FULL_VERSION = 1.7.0-internal-administrator_2013_02_06_23_32-b00 >>>> BUILD_NUMBER = b00 >>>> >>>> External File/Binary Locations: >>>> USRJDKINSTANCES_PATH = C:/PROGRA~1/Java BUILD_JDK_IMPORT_PATH = >>>> c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries >>>> ALT_BUILD_JDK_IMPORT_PATH = >>>> JDK_IMPORT_PATH = >>>> c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries/windows-amd64 >>>> ALT_JDK_IMPORT_PATH = >>>> LANGTOOLS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist >>>> ALT_LANGTOOLS_DIST = >>>> C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist >>>> CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >>>> ALT_CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >>>> JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >>>> ALT_JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >>>> JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >>>> ALT_JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >>>> HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR >>>> ALT_HOTSPOT_DOCS_IMPORT_PATH = >>>> HOTSPOT_IMPORT_PATH = >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>>> ALT_HOTSPOT_IMPORT_PATH = >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>>> HOTSPOT_SERVER_PATH = >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/jre/bin/server >>>> ALT_HOTSPOT_SERVER_PATH = >>>> HOTSPOT_LIB_PATH = >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/lib >>>> ALT_HOTSPOT_LIB_PATH = >>>> DXSDK_VER = 0x0900 >>>> DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 >>>> ALT_DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 DXSDK_INCLUDE_PATH = >>>> C:/PROGRA~2/MI4ADD~1/Include >>>> ALT_DXSDK_INCLUDE_PATH = >>>> DXSDK_LIB_PATH = C:/PROGRA~2/MI4ADD~1/Lib/x64 >>>> ALT_DXSDK_LIB_PATH = >>>> WINDOWSSDKDIR = C:/PROGRA~2/MICROS~1/Windows/v7.0a/ >>>> ALT_WINDOWSSDKDIR = >>>> RC = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/RC.Exe >>>> REBASE = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/ReBase.Exe >>>> CACERTS_FILE = ./../src/share/lib/security/cacerts >>>> ALT_CACERTS_FILE = >>>> >>>> OpenJDK-specific settings: >>>> FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include >>>> ALT_FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include >>>> FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 >>>> ALT_FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 >>>> >>>> Previous JDK Settings: >>>> PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE >>>> ALT_PREVIOUS_RELEASE_PATH = >>>> PREVIOUS_JDK_VERSION = 1.6.0 >>>> ALT_PREVIOUS_JDK_VERSION = >>>> PREVIOUS_JDK_FILE = >>>> ALT_PREVIOUS_JDK_FILE = >>>> PREVIOUS_JRE_FILE = >>>> ALT_PREVIOUS_JRE_FILE = >>>> PREVIOUS_RELEASE_IMAGE = c:/OpenJDK/jdk-6u18 >>>> ALT_PREVIOUS_RELEASE_IMAGE = >>>> >>>> >>>> WARNING: To build Java 2 SDK 1.7.0 you need : >>>> VS2010 - link.exe version '10.00.30319.01' >>>> Specifically the Visual Studio 10 link.exe. >>>> You appear to be using Linker version '10.00.40219.01' >>>> >>>> Sanity check passed. >>>> make \ >>>> SKIP_FASTDEBUG_BUILD=true \ >>>> SKIP_DEBUG_BUILD=true \ >>>> \ >>>> generic_build_repo_series >>>> make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk' >>>> /usr/bin/mkdir -p ./build/windows-amd64/j2sdk-image /usr/bin/mkdir -p >>>> C:/OpenJDK/openjdk/build/windows-amd64/langtools >>>> >>>> == End of listing of make sanity portion of build == >>>> >>>> > > From rnielsen at vocera.com Sat Feb 9 02:35:22 2013 From: rnielsen at vocera.com (Randy Nielsen) Date: Fri, 8 Feb 2013 18:35:22 -0800 Subject: Hang building JDK 7 Hotspot in Windows 7 In-Reply-To: References: <1AC3281AD57A34468B9879C754022CAF05F1497130@exchange.vocera.local> <29D2F8E5-D2E7-441F-86C7-63888F114A8F@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F14975BE@exchange.vocera.local> <5114ACA5.7080908@oracle.com> <511514E4.2070108@oracle.com> Message-ID: <1AC3281AD57A34468B9879C754022CAF05F1497B46@exchange.vocera.local> Fixed! One of our very capable Linux engineers, Suresh Rajashekarak, found a Cygwin 1.6.9 mirror at redhat: ftp://ftp.ges.redhat.com/private/releng/cygwin-1.6/ Setup is now called rhsetup.exe. With this I successfully built JDK 1.7 Hotspot on 64 bit Windows 7. I had one more problem building Hotspot. My Windows PATH had the vc/bin/amd_x64 and vc/bin/x64 in the wrong order. The vc/bin/amd64 entry must be before the vc/bin/x86_amd. In Cygwin typing "cl" in with the path in the correct order produces something like this: $ cl Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] Whereas with the order flipped typing "cl" produces no output. Randy -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Friday, February 08, 2013 10:45 AM To: Tim Bell Cc: Randy Nielsen; build-dev at openjdk.java.net; Suresh Rajashekara; Suresh at sca-git1.sun.com Subject: Re: Hang building JDK 7 Hotspot in Windows 7 Sorry to say this, but I think this is a problem of new Cygwin versions. I've just tried with the newest 1.7.17 (see "uname -r") under Windows Server 2003 and it hangs as well. I really think that all has been already said about this topic, see: http://openjdk.5641.n7.nabble.com/Is-anyone-able-to-build-on-Win-7-td81697.html#a33196055 http://weblogs.java.net/blog/simonis/archive/2011/10/28/yaojowbi-yet-another-openjdk-windows-build-instruction If nobody will be able to provide a complete Cygwin version 1.7.9 or older (actually, that's my best guess:) I think we will be out of luck. I've tried the whole afternoon to download such a version without success. If somebody else succeeds, PLEASE, PLEASE make it available somewhere for download otherwise I don't see how anybody else will ever be able to build OpenJDK 7 on Windows except on machines which have been set up years ago. The only alternatives are: - use MKS ($$$$) - use the new build system (currently only for JDK8) - use MinGW/MSYS (not sure what the current status of MinGW/MSYS support is in JDK7 because I've submitted these changes about a year ago. I think most of them have been integrated, but mostly to the jdk8 repositories (see http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html which contains some hints for MinGW/MSYS builds). As far as I can see they are not in the jdk7 README (http://hg.openjdk.java.net/jdk7u/jdk7u/raw-file/tip/README-builds.html) so the build file changes may still have to be back-ported ) . Regards, Volker On Fri, Feb 8, 2013 at 4:08 PM, Tim Bell wrote: > For the hotspot build, 'gmake MAKE_VERBOSE=y' or 'gmake QUIETLY=' > gives more details. > > You need 'nmake' on your PATH when building in hotspot. > > Also, verify that the VS2010 'link' is on PATH _before_ the Cygwin link.exe. > > http://hg.openjdk.java.net/jdk7u/jdk7u/raw-file/7ffd73535b8e/README-bu > ilds.html#msvc32 > > > Hope this helps- > > Tim > > > On 02/07/13 23:43, Erik Joelsson wrote: >> >> The LOG=debug is JDK8 and build-infra specific. For JDK7 I don't know >> of a way to get more info except adding the -d or --debug flag to >> make, which as David says is rather useless most of the time. >> >> /Erik >> >> On 2013-02-08 00:47, Randy Nielsen wrote: >>> >>> Tried suggestions with no change. Specifically LOG=debug,nofile >>> didn't add any output at all. Are there any others ways to poke the >>> make to get more output, say a line by line trace of the make >>> behavior? This feels like a process synchronization problem where >>> process A is waiting to be notified by someone and of course the >>> notify never occurs. But why would a bunch of compiles etc. use this kind of synchronization? >>> >>> Also I tried strace to peek under the covers, and concluded that >>> Cygwin strace is very buggy. Details (optional) follow, after my signature. >>> >>> Randy >>> >>> I ran strace on top of the make of hotspot and to my utter >>> astonishment after a few seconds it ended like this: >>> >>> $ strace make hotspot>strace.txt >>> /bin/sh: >>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link: >>> Function not implemented >>> jdk/make/common/shared/Compiler-msvc.gmk:80: *** >>> COMPILER_VERSION cannot be empty here. Stop. >>> >>> Being a suspicious soul I then tried this: >>> >>> $ strace make sanity>trace.txt >>> /bin/sh: >>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link: >>> Function not implemented >>> jdk/make/common/shared/Compiler-msvc.gmk:80: *** >>> COMPILER_VERSION cannot be empty here. Stop. >>> >>> Of course the "make sanity" without strace works perfectly. Conclusion: >>> the Cygwin strace is buggy (big surprise) and can't be used to help >>> peer "under the covers" of the hotspot make. >>> >>> >>> -----Original Message----- >>> From: Kelly Ohair [mailto:kelly.ohair at oracle.com] >>> Sent: Thursday, February 07, 2013 8:36 AM >>> To: Randy Nielsen >>> Cc: build-dev at openjdk.java.net >>> Subject: Re: Hang building JDK 7 Hotspot in Windows 7 >>> >>> no definite answers just ideas >>> >>> we are starting to use windows 2008R2 which seems better make sure >>> the env vars TMP and TEMP are set to directories windows understands >>> eg C:/ paths and these directories exist and have write permissions >>> try using make LOG=debug,nofile >>> >>> >>> Sent from my iPhone >>> >>> On Feb 6, 2013, at 23:59, Randy Nielsen wrote: >>> >>>> I am thoroughly stuck building JDK 7 when I start the Hotspot >>>> portion of the build. This is Windows 7 64 bit building 64 bit JDK >>>> with Visual Studio >>>> 10 Service Pack 1. The hang seems to happen immediately after I >>>> start the hotspot portion of the make. There is no output at all. >>>> Watching the Windows Task Manager in the Processes tab shows the >>>> System Idle process at 99% almost all of the time. Occasionally >>>> mscorsvw.exe (.NET services) or minty.exe gets a few % of CPU but only very briefly. >>>> >>>>> From browsing the web I've tried the following "fixes": verified >>>>> that there was no anti-virus program, and disabled ASLR (Address >>>>> Space Layout Randomization). No change in behavior. >>>> >>>> Has anyone any ideas about how to deal with this? Also are there >>>> settings in the make that will dramatically increase the level of >>>> logging in the make that might help me debug this? >>>> >>>> Here's the output of the make hotspot: >>>> >>>> /usr/bin/mkdir -p >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >>>> /usr/bin/mkdir -p >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>>> >>>> >>>> ################################################################### >>>> ### >>>> ## >>>> ######################################################################## >>>> ##### Entering hotspot for target(s) all_product ##### >>>> ################################################################### >>>> ### >>>> ## >>>> >>>> cd ./hotspot/make&& \ >>>> make JDK_TOPDIR=C:/OpenJDK/openjdk/jdk >>>> JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared >>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >>>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 >>>> JDK_BUILD_NUMBER=b00 >>>> FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 >>>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 >>>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 >>>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 >>>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 >>>> ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" >>>> ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/output >>>> dir >>>> ALT_EXPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/impo >>>> rt ALT_SLASH_JAVA="c:/OpenJDK" ALT_BOOTDIR=c:/OpenJDK/jdk-6u18 >>>> ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools >>>> /di >>>> st all_product >>>> >>>> ==>> That's it - no more output. >>>> >>>> The output of the sanity portion of the make is below. >>>> >>>> Hoping someone can help! >>>> >>>> Randy >>>> >>>> $ make >>>> cygwin warning: >>>> MS-DOS style path detected: C:/Windows/system32/wscript.exe >>>> Preferred POSIX equivalent is: >>>> /cygdrive/c/Windows/system32/wscript.exe >>>> CYGWIN environment variable option "nodosfilewarning" turns off >>>> this warning. >>>> Consult the user's guide for more details about POSIX paths: >>>> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames >>>> ( cd ./jdk/make&& \ >>>> make sanity HOTSPOT_IMPORT_CHECK=false >>>> JDK_TOPDIR=C:/OpenJDK/openjdk/jdk >>>> JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared >>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >>>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 >>>> JDK_BUILD_NUMBER=b00 >>>> FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 >>>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 >>>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 >>>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 >>>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 >>>> ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" >>>> ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64 >>>> ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools >>>> /di st >>>> ALT_CORBA_DIST=C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >>>> ALT_JAXP_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >>>> ALT_JAXWS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >>>> ALT_HOTSPOT_IMPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hots >>>> pot >>>> /import BUILD_HOTSPOT=true ; ) >>>> make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' >>>> make[1]: Leaving directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' >>>> >>>> Build Machine Information: >>>> build machine = WIN-R7HSHTAIIHC >>>> >>>> Build Directory Structure: >>>> CWD = /cygdrive/c/OpenJDK/openjdk >>>> TOPDIR = . >>>> LANGTOOLS_TOPDIR = ./langtools >>>> JAXP_TOPDIR = ./jaxp >>>> JAXWS_TOPDIR = ./jaxws >>>> CORBA_TOPDIR = ./corba >>>> HOTSPOT_TOPDIR = ./hotspot >>>> JDK_TOPDIR = ./jdk >>>> >>>> Build Directives: >>>> BUILD_LANGTOOLS = true >>>> BUILD_JAXP = true >>>> BUILD_JAXWS = true >>>> BUILD_CORBA = true >>>> BUILD_HOTSPOT = true >>>> BUILD_JDK = true >>>> DEBUG_CLASSFILES = >>>> DEBUG_BINARIES = >>>> >>>> Hotspot Settings: >>>> HOTSPOT_BUILD_JOBS = >>>> HOTSPOT_OUTPUTDIR = >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >>>> HOTSPOT_EXPORT_PATH = >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>>> >>>> >>>> >>>> >>>> Bootstrap Settings: >>>> BOOTDIR = c:/OpenJDK/jdk-6u18 >>>> ALT_BOOTDIR = c:/OpenJDK/jdk-6u18 >>>> BOOT_VER = 1.6.0 [requires at least 1.6] OUTPUTDIR = >>>> C:/OpenJDK/openjdk/build/windows-amd64 >>>> ALT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 >>>> ABS_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 >>>> >>>> Build Tool Settings: >>>> SLASH_JAVA = c:/OpenJDK >>>> ALT_SLASH_JAVA = c:/OpenJDK >>>> VARIANT = OPT >>>> JDK_DEVTOOLS_DIR = c:/OpenJDK/devtools >>>> ALT_JDK_DEVTOOLS_DIR = >>>> ANT_HOME = c:/OpenJDK/apache-ant-1.7.1 UNIXCOMMAND_PATH = /usr/bin/ >>>> ALT_UNIXCOMMAND_PATH = >>>> COMPILER_PATH = >>>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/ >>>> ALT_COMPILER_PATH = >>>> DEVTOOLS_PATH = /usr/bin/ >>>> ALT_DEVTOOLS_PATH = >>>> MSVCRNN_DLL_PATH = >>>> C:/PROGRA~2/MICROS~2.0/Vc/redist/x64/Microsoft.VC100.CRT >>>> ALT_MSVCRNN_DLL_PATH = >>>> INCLUDE = >>>> C:/PROGRA~2/MICROS~2.0/VC/include;C:/MSSDKWIN7/Windows/v7.1/Include >>>> LIB = >>>> C:/PROGRA~2/MICROS~2.0/VC/lib/amd64;C:/MSSDKWIN7/Windows/v7.1/Lib/x64 >>>> COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) >>>> COMPILER_VERSION = VS2010 CC_VER = 16.00.40219.01 [requires at >>>> least 16.00.30319.01] ZIP_VER = 3.0 [requires at least 2.2] >>>> UNZIP_VER = >>>> 6.00 [requires at least 5.12] LINK_VER = 10.00.40219.01 [requires >>>> at least 10.00.30319.01] CC = >>>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/cl >>>> LINK = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link >>>> DUMPBIN = >>>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe >>>> ANT_VER = 1.7.1 [requires at least 1.7.1] TEMPDIR = >>>> C:/OpenJDK/openjdk/build/windows-amd64/tmp >>>> >>>> Build Directives: >>>> OPENJDK = true >>>> USE_HOTSPOT_INTERPRETER_MODE = >>>> PEDANTIC = >>>> DEV_ONLY = >>>> NO_DOCS = >>>> NO_IMAGES = >>>> TOOLS_ONLY = >>>> INSANE = >>>> COMPILE_APPROACH = normal >>>> FASTDEBUG = >>>> COMPILER_WARNINGS_FATAL = false >>>> COMPILER_WARNING_LEVEL = 3 >>>> SHOW_ALL_WARNINGS = false >>>> INCREMENTAL_BUILD = false >>>> CC_HIGHEST_OPT = >>>> CC_HIGHER_OPT = >>>> CC_LOWER_OPT = >>>> CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D >>>> _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- >>>> -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb >>>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 >>>> -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >>>> CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D >>>> _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- >>>> -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb >>>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 >>>> -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >>>> BOOT_JAVA_CMD = c:/OpenJDK/jdk-6u18/bin/java -XX:-PrintVMOptions >>>> -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m >>>> -XX:PermSize=32m -XX:MaxPermSize=160m BOOT_JAVAC_CMD = >>>> c:/OpenJDK/jdk-6u18/bin/javac -J-XX:ThreadStackSize=1536 >>>> -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions >>>> -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m >>>> -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 >>>> -XDignore.symbol.file=true BOOT_JAR_CMD = >>>> c:/OpenJDK/jdk-6u18/bin/jar BOOT_JARSIGNER_CMD = >>>> c:/OpenJDK/jdk-6u18/bin/jarsigner >>>> >>>> Build Platform Settings: >>>> USER = Administrator >>>> PLATFORM = windows >>>> ARCH = amd64 >>>> LIBARCH = amd64 >>>> ARCH_FAMILY = amd64 >>>> ARCH_DATA_MODEL = 64 >>>> ARCHPROP = amd64 >>>> PROCESSOR_ARCHITECTURE = x86 >>>> PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 26 Stepping 5, >>>> GenuineIntel USING_CYGWIN = true CYGWIN_VER = 6.1 [requires at >>>> least 4.0] CYGPATH_CMD = cygpath -a -s -m OS_VERSION = 6.1 >>>> [requires at least 5.2] OS_VARIANT_NAME = OS_VARIANT_VERSION = >>>> 6.1 MB_OF_MEMORY = 8191 >>>> >>>> GNU Make Settings: >>>> MAKE = make >>>> MAKE_VER = 3.82 [requires at least 3.81] MAKECMDGOALS = sanity >>>> MAKEFLAGS = w SHELL = /bin/sh >>>> >>>> Target Build Versions: >>>> JDK_VERSION = 1.7.0 >>>> MILESTONE = internal >>>> RELEASE = 1.7.0-internal >>>> FULL_VERSION = 1.7.0-internal-administrator_2013_02_06_23_32-b00 >>>> BUILD_NUMBER = b00 >>>> >>>> External File/Binary Locations: >>>> USRJDKINSTANCES_PATH = C:/PROGRA~1/Java BUILD_JDK_IMPORT_PATH = >>>> c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries >>>> ALT_BUILD_JDK_IMPORT_PATH = >>>> JDK_IMPORT_PATH = >>>> c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries/windows-amd64 >>>> ALT_JDK_IMPORT_PATH = >>>> LANGTOOLS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist >>>> ALT_LANGTOOLS_DIST = >>>> C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist >>>> CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >>>> ALT_CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >>>> JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >>>> ALT_JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >>>> JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >>>> ALT_JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >>>> HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR >>>> ALT_HOTSPOT_DOCS_IMPORT_PATH = >>>> HOTSPOT_IMPORT_PATH = >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>>> ALT_HOTSPOT_IMPORT_PATH = >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>>> HOTSPOT_SERVER_PATH = >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/jre/bin/server >>>> ALT_HOTSPOT_SERVER_PATH = >>>> HOTSPOT_LIB_PATH = >>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/lib >>>> ALT_HOTSPOT_LIB_PATH = >>>> DXSDK_VER = 0x0900 >>>> DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 >>>> ALT_DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 DXSDK_INCLUDE_PATH = >>>> C:/PROGRA~2/MI4ADD~1/Include >>>> ALT_DXSDK_INCLUDE_PATH = >>>> DXSDK_LIB_PATH = C:/PROGRA~2/MI4ADD~1/Lib/x64 >>>> ALT_DXSDK_LIB_PATH = >>>> WINDOWSSDKDIR = C:/PROGRA~2/MICROS~1/Windows/v7.0a/ >>>> ALT_WINDOWSSDKDIR = >>>> RC = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/RC.Exe >>>> REBASE = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/ReBase.Exe >>>> CACERTS_FILE = ./../src/share/lib/security/cacerts >>>> ALT_CACERTS_FILE = >>>> >>>> OpenJDK-specific settings: >>>> FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include >>>> ALT_FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include >>>> FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 >>>> ALT_FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 >>>> >>>> Previous JDK Settings: >>>> PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE >>>> ALT_PREVIOUS_RELEASE_PATH = >>>> PREVIOUS_JDK_VERSION = 1.6.0 >>>> ALT_PREVIOUS_JDK_VERSION = >>>> PREVIOUS_JDK_FILE = >>>> ALT_PREVIOUS_JDK_FILE = >>>> PREVIOUS_JRE_FILE = >>>> ALT_PREVIOUS_JRE_FILE = >>>> PREVIOUS_RELEASE_IMAGE = c:/OpenJDK/jdk-6u18 >>>> ALT_PREVIOUS_RELEASE_IMAGE = >>>> >>>> >>>> WARNING: To build Java 2 SDK 1.7.0 you need : >>>> VS2010 - link.exe version '10.00.30319.01' >>>> Specifically the Visual Studio 10 link.exe. >>>> You appear to be using Linker version '10.00.40219.01' >>>> >>>> Sanity check passed. >>>> make \ >>>> SKIP_FASTDEBUG_BUILD=true \ >>>> SKIP_DEBUG_BUILD=true \ >>>> \ >>>> generic_build_repo_series >>>> make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk' >>>> /usr/bin/mkdir -p ./build/windows-amd64/j2sdk-image /usr/bin/mkdir >>>> -p C:/OpenJDK/openjdk/build/windows-amd64/langtools >>>> >>>> == End of listing of make sanity portion of build == >>>> >>>> > > From rnielsen at vocera.com Sat Feb 9 03:07:23 2013 From: rnielsen at vocera.com (Randy Nielsen) Date: Fri, 8 Feb 2013 19:07:23 -0800 Subject: build JDK 7 Windows 7: make jdk fails building sounds Message-ID: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> "make jdk" fails building JavaX Sounds library in the include file objidl.h. Output is below. The compiler fails trying to use this: "__RPC__out_xcount_part". The web suggests that the fix is obtained by placing your SDK entries before your VC entries in the PATH and the LIB. I've done this but failure is the same. Does anyone have any suggestions? Randy Building lib:C:/OpenJDK/openjdk/build/windows-amd64/bin/jsoundds.dll "C:/PROGRA~2/MICROS~2.0/Common7/Tools"/../../Vc/bin/amd64/cl -O1 -Zi -nologo -M D /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJ DK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_W inOS_DirectSound.pdb -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sou nd/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 -D _CRT_SECURE_ NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE -DNDEBUG -DWIN32 -DIAL -D_LITTLE_END IAN -D_AMD64_ -Damd64 -DWIN32_LEAN_AND_MEAN -I. -IC:/OpenJDK/openjdk/build/windo ws-amd64/tmp/sun/javax.sound/jsoundds/CClassHeaders -I../../../../src/windows/ja vavm/export -I../../../../src/share/javavm/export -I../../../../src/share/native /common -I../../../../src/windows/native/common -I../../../../src/share/native/j avax/sound -I../../../../src/windows/native/javax/sound -DX_PLATFORM=X_WINDOWS -DX_ARCH=X_AMD64 -DUSE_DAUDIO=TRUE -I../../../../src/share/native/com/sun/media /sound -IC:/PROGRA~2/MI4ADD~1/Include -c -FoC:/OpenJDK/openjdk/build/windows-am d64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.obj ../.. /../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_DirectSound.cpp PLATFORM_API_WinOS_DirectSound.cpp C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11280) : error C2061: syntax error : identifier '__RPC__out_xcount_part' C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : error C2059: syntax error : ')' C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : fatal error C1903: unable to recover from previous error(s); stopping compilation make[4]: *** [C:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundd s/obj64/PLATFORM_API_WinOS_DirectSound.obj] Error 2 make[4]: Leaving directory `/cygdrive/c/OpenJDK/openjdk/jdk/make/javax/sound/jso From erik.joelsson at oracle.com Mon Feb 11 08:38:43 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 Feb 2013 09:38:43 +0100 Subject: RFR (S): 8007639: Workaround for ccache in vm.make is incorrect In-Reply-To: <5115442C.5030309@oracle.com> References: <5115442C.5030309@oracle.com> Message-ID: <5118AE13.9000505@oracle.com> Looks good to me. /Erik On 2013-02-08 19:30, Mikael Vidstedt wrote: > > Please review the following change: > > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.00/webrev > Bug: http://bugs.sun.com/view_bug.do?bug_id=8007639 > > This change corrects the workaround that was introduced in vm.make for > enabling ccache for HotSpot builds. The change introduces a file > specific makefile variable (CFLAGS/) which is used to only set > the JRE_RELEASE_VERSION define when compiling vm_version.o. > > Verified manually by observing command lines with/without fix, also > passes JPRT. > > > Some additional background below, more information is available in the > bug report: > > To enable the use of ccache 7132779 [1] introduced some new makefile > logic in vm.make to only pass the JRE_RELEASE_VERSION define when > compiling the vm_version.cpp file. The underlying reason for that is > that the JRE_RELEASE_VERSION can in some cases contain a time stamp > and since ccache checks that the defines match before reusing the > cache version of the object file that would mean that if the time > stamp changed all files would have to be recompiled. With the fix only > vm_version.cpp needs to be recompiled. > > This almost works, but the logic introduced in the makefile is > actually incorrect. Today it looks like this: > > > # This is VERY important! The version define must only be supplied to > vm_version.o > # If not, ccache will not re-use the cache at all, since the version > string might contain > # a time and date. > vm_version.o: CXXFLAGS += ${JRE_VERSION} > > However, the above syntax does not only add the ${JRE_VERSION} to the > CXXFLAGS of vm_version.o as originally intended - it also /in some > cases/ adds it to the CXXFLAGS for any and all prerequisites of > vm_version.o. And vm_version.o depends on all other object files, > which means in theory this actually passes in that potentially time > stamped version string define to all object files anyway. For various > reasons in reality it only passes it to files that are > lexicographically after vm_version.o - see bug report for more > background on why - but there's still a handful of files that will be > recompiled unnecessarily. > > Cheers, > Mikael > > [1] http://bugs.sun.com/view_bug.do?bug_id=7132779 > From alexandr.scherbatiy at oracle.com Mon Feb 11 11:22:30 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 11 Feb 2013 15:22:30 +0400 Subject: OpenJDK rebuilding on windows takes a long time In-Reply-To: <51150FB3.7@oracle.com> References: <5114ED06.1040802@oracle.com> <51150FB3.7@oracle.com> Message-ID: <5118D476.6030203@oracle.com> On 2/8/2013 6:46 PM, Erik Joelsson wrote: > Ccache is not supported on windows since it doesn't work with visual > studio AFAIK. > > What kind of change did you do? Was it in native code or java and in > which repository? I use the http://hg.openjdk.java.net/jdk8/awt repository, edit java code and build the jdk. To reproduce the issue: - open the javax.swing.JFrame class and add a comment line: // a comment - build jdk ----- Build times ------- Start 2013-02-11 15:09:55 End 2013-02-11 15:17:08 00:00:03 corba 00:00:02 hotspot 00:00:01 jaxp 00:00:03 jaxws 00:06:54 jdk 00:00:02 langtools 00:07:13 TOTAL ------------------------- My environment: OS: Windows 7 Professional, x64 Processor - Intel Core i7 Memory - 8 GB The log file is attached. Thanks, Alexandr. > > /Erik > -------------- next part -------------- $ make Building Java(TM) for target 'default' in configuration 'windows-x86-normal-serv er-release' ## Starting langtools ## Finished langtools (build time 00:00:02) ## Starting hotspot ## Finished hotspot (build time 00:00:02) ## Starting corba ## Finished corba (build time 00:00:03) ## Starting jaxp ## Finished jaxp (build time 00:00:01) ## Starting jaxws ## Finished jaxws (build time 00:00:03) ## Starting jdk Generating beaninfo Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output t runcated Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output t runcated Compiling 9817 files for BUILD_JDK c:\Sun\OpenJDK\jdk8-awt\jdk\src\share\classes\jdk\internal\org\objectweb\asm\uti l\CheckMethodAdapter.java:1209: warning: '_' used as an identifier } catch (IllegalArgumentException _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\jdk8-awt\jdk\src\share\classes\jdk\internal\org\objectweb\asm\uti l\CheckMethodAdapter.java:1283: warning: '_' used as an identifier } catch (IllegalArgumentException _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\jdk8-awt\jdk\src\windows\classes\java\net\DualStackPlainSocketImp l.java:255: warning: auxiliary class InetAddressContainer in c:\Sun\OpenJDK\jdk8 -awt\jdk\src\share\classes\java\net\AbstractPlainSocketImpl.java should not be a ccessed from outside its own source file static native void localAddress(int fd, InetAddressContainer in) throws Sock etException; ^ c:\Sun\OpenJDK\jdk8-awt\jdk\src\share\classes\java\awt\EventDispatchThread.java: 123: warning: non-varargs call of varargs method with inexact argument type for last parameter; final Method evaluateMethod = Class.forName("sun.lwawt.macosx.Ev entDispatchAccess").getMethod("evaluate", null); ^ cast to Class for a varargs call cast to Class[] for a non-varargs call and to suppress this warning c:\Sun\OpenJDK\jdk8-awt\jdk\src\share\classes\java\awt\EventDispatchThread.java: 126: warning: non-varargs call of varargs method with inexact argument type for last parameter; return ((Boolean)evaluateMethod.invoke(cond, null)).bool eanValue(); ^ cast to Object for a varargs call cast to Object[] for a non-varargs call and to suppress this warning c:\Sun\OpenJDK\jdk8-awt\jdk\src\windows\classes\java\net\DualStackPlainSocketImp l.java:205: warning: auxiliary class InetAddressContainer in c:\Sun\OpenJDK\jdk8 -awt\jdk\src\share\classes\java\net\AbstractPlainSocketImpl.java should not be a ccessed from outside its own source file localAddress(nativefd, (InetAddressContainer)iaContainerObj); ^ c:\Sun\OpenJDK\jdk8-awt\jdk\src\windows\classes\java\net\TwoStacksPlainSocketImp l.java:116: warning: auxiliary class InetAddressContainer in c:\Sun\OpenJDK\jdk8 -awt\jdk\src\share\classes\java\net\AbstractPlainSocketImpl.java should not be a ccessed from outside its own source file InetAddressContainer in = new InetAddressContainer(); ^ c:\Sun\OpenJDK\jdk8-awt\jdk\src\windows\classes\java\net\TwoStacksPlainSocketImp l.java:116: warning: auxiliary class InetAddressContainer in c:\Sun\OpenJDK\jdk8 -awt\jdk\src\share\classes\java\net\AbstractPlainSocketImpl.java should not be a ccessed from outside its own source file InetAddressContainer in = new InetAddressContainer(); ^ Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 8 warnings Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output t runcated Compiling 1 files for BUILD_ACCESSBRIDGE_32 Compiling 1 files for BUILD_ALTCLASSES Compiling 1 files for BUILD_ACCESSBRIDGE_LEGACY Note: c:\Sun\OpenJDK\jdk8-awt\jdk\src\closed\share\altclasses\java\util\TreeMap. java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output t runcated Note: c:\Sun\OpenJDK\jdk8-awt\build\windows-x86-normal-server-release\jdk\gensrc _ab\32bit\com\sun\java\accessibility\AccessBridge.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output t runcated Note: c:\Sun\OpenJDK\jdk8-awt\build\windows-x86-normal-server-release\jdk\gensrc _ab\legacy\com\sun\java\accessibility\AccessBridge.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output t runcated ## Finished jdk (build time 00:06:54) ----- Build times ------- Start 2013-02-11 15:09:55 End 2013-02-11 15:17:08 00:00:03 corba 00:00:02 hotspot 00:00:01 jaxp 00:00:03 jaxws 00:06:54 jdk 00:00:02 langtools 00:07:13 TOTAL ------------------------- Finished building Java(TM) for target 'default' From erik.joelsson at oracle.com Mon Feb 11 12:03:20 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 Feb 2013 13:03:20 +0100 Subject: OpenJDK rebuilding on windows takes a long time In-Reply-To: <5118D476.6030203@oracle.com> References: <5114ED06.1040802@oracle.com> <51150FB3.7@oracle.com> <5118D476.6030203@oracle.com> Message-ID: <5118DE08.4080709@oracle.com> The long term solution to this is sjavac. I do not know if it has made it into that forest yet. You can try by adding --enable-sjavac to configure and do a clean build. If the build works, you have it, and incremental builds will be much faster. /Erik On 2013-02-11 12:22, Alexander Scherbatiy wrote: > On 2/8/2013 6:46 PM, Erik Joelsson wrote: >> Ccache is not supported on windows since it doesn't work with visual >> studio AFAIK. >> >> What kind of change did you do? Was it in native code or java and in >> which repository? > I use the http://hg.openjdk.java.net/jdk8/awt repository, edit java > code and build the jdk. > To reproduce the issue: > - open the javax.swing.JFrame class and add a comment line: > // a comment > - build jdk > > ----- Build times ------- > Start 2013-02-11 15:09:55 > End 2013-02-11 15:17:08 > 00:00:03 corba > 00:00:02 hotspot > 00:00:01 jaxp > 00:00:03 jaxws > 00:06:54 jdk > 00:00:02 langtools > 00:07:13 TOTAL > ------------------------- > > My environment: > OS: Windows 7 Professional, x64 > Processor - Intel Core i7 > Memory - 8 GB > > The log file is attached. > > Thanks, > Alexandr. >> >> /Erik >> > From volker.simonis at gmail.com Mon Feb 11 19:36:41 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 11 Feb 2013 20:36:41 +0100 Subject: Hang building JDK 7 Hotspot in Windows 7 In-Reply-To: <1AC3281AD57A34468B9879C754022CAF05F1497B46@exchange.vocera.local> References: <1AC3281AD57A34468B9879C754022CAF05F1497130@exchange.vocera.local> <29D2F8E5-D2E7-441F-86C7-63888F114A8F@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F14975BE@exchange.vocera.local> <5114ACA5.7080908@oracle.com> <511514E4.2070108@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1497B46@exchange.vocera.local> Message-ID: On Sat, Feb 9, 2013 at 3:35 AM, Randy Nielsen wrote: > Fixed! > > One of our very capable Linux engineers, Suresh Rajashekarak, found a Cygwin 1.6.9 mirror at redhat: ftp://ftp.ges.redhat.com/private/releng/cygwin-1.6/ Setup is now called rhsetup.exe. > Actually he seems to be more than very capable - he seems to be a true clairvoyant:) So it's the first time I hear about "RedHat Cygwin". I found the following page for it: http://www.redhat.com/services/custom/cygwin/ which links to ftp://ftp.ges.redhat.com/private/releng/cygwin-1.8/rhsetup.exe (named the "Red Hat Cygwin official installation utility"). Unfortunately the ftp-site is not browsable, so you have to know what you want to download. The current release is RedHat Cygwin 1.8 which seems to be ahead of the current Cygwin 1.7.17. Has anybody tried with the newest RedHat Cygwin? Does the build still hang? > With this I successfully built JDK 1.7 Hotspot on 64 bit Windows 7. > Great to see the confirmation that it is really a problem of newer Cygwin versions. I tried to install the RedHat Cygwin 1.6.9 from you link but unfortunately the installer crashes immediately on my Windows Server 2003 64-bit machine. So I used a vanilla Cygwin installer and entered ftp://ftp.ges.redhat.com/private/releng/cygwin-1.6 as mirror which installed successfully. Unfortunately I realized that Cygwin before 1.7 uses registry entries to locate the cygwin.dll and root mount points and I had another ancient Cygwin 1.5. so after the installation, neither of them did work any more. Fortunately I did found a Cygwin 1.7.9 in one of my VirtualBox images. I copied it over to my Windows 2003 64-bit server and voila - the build succeeded. The good thing about Cygwin 1.7 is that is is self contained and relocatable (i.e. it doesn't need any registry entries because it finds all it's DLLs from the path of its execuatables). With this version of Cygwin 1.7.9 I've successfully build on Windows XP 64-bit, Windows Server 2003 64-bit and Windows 7 64-bit (although I had to disable "on access virus scanning" and "ASLR (Address Space Layout Randomization)" - see http://mail.openjdk.java.net/pipermail/build-dev/2012-February/005594.html). So to cut a long story short - it seems you need Cygwin <= 1.7.9 in order to build on Windows. It would be really nice if this could be hosted somewhere on java.net (after all it's GPL like OpenJDK :) and mentioned in the README. > I had one more problem building Hotspot. My Windows PATH had the vc/bin/amd_x64 and vc/bin/x64 in the wrong order. The vc/bin/amd64 entry must be before the vc/bin/x86_amd. In Cygwin typing "cl" in with the path in the correct order produces something like this: > > $ cl > Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64 > Copyright (C) Microsoft Corporation. All rights reserved. > > usage: cl [ option... ] filename... [ /link linkoption... ] > > Whereas with the order flipped typing "cl" produces no output. > > Randy > > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Friday, February 08, 2013 10:45 AM > To: Tim Bell > Cc: Randy Nielsen; build-dev at openjdk.java.net; Suresh Rajashekara; Suresh at sca-git1.sun.com > Subject: Re: Hang building JDK 7 Hotspot in Windows 7 > > Sorry to say this, but I think this is a problem of new Cygwin versions. > I've just tried with the newest 1.7.17 (see "uname -r") under Windows Server 2003 and it hangs as well. > > I really think that all has been already said about this topic, see: > > http://openjdk.5641.n7.nabble.com/Is-anyone-able-to-build-on-Win-7-td81697.html#a33196055 > http://weblogs.java.net/blog/simonis/archive/2011/10/28/yaojowbi-yet-another-openjdk-windows-build-instruction > > If nobody will be able to provide a complete Cygwin version 1.7.9 or older (actually, that's my best guess:) I think we will be out of luck. > I've tried the whole afternoon to download such a version without success. If somebody else succeeds, PLEASE, PLEASE make it available somewhere for download otherwise I don't see how anybody else will ever be able to build OpenJDK 7 on Windows except on machines which have been set up years ago. > > The only alternatives are: > - use MKS ($$$$) > - use the new build system (currently only for JDK8) > - use MinGW/MSYS (not sure what the current status of MinGW/MSYS support is in JDK7 because I've submitted these changes about a year ago. I think most of them have been integrated, but mostly to the jdk8 repositories (see http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html > which contains some hints for MinGW/MSYS builds). As far as I can see they are not in the jdk7 README > (http://hg.openjdk.java.net/jdk7u/jdk7u/raw-file/tip/README-builds.html) > so the build file changes may still have to be back-ported ) . > > Regards, > Volker > > On Fri, Feb 8, 2013 at 4:08 PM, Tim Bell wrote: >> For the hotspot build, 'gmake MAKE_VERBOSE=y' or 'gmake QUIETLY=' >> gives more details. >> >> You need 'nmake' on your PATH when building in hotspot. >> >> Also, verify that the VS2010 'link' is on PATH _before_ the Cygwin link.exe. >> >> http://hg.openjdk.java.net/jdk7u/jdk7u/raw-file/7ffd73535b8e/README-bu >> ilds.html#msvc32 >> >> >> Hope this helps- >> >> Tim >> >> >> On 02/07/13 23:43, Erik Joelsson wrote: >>> >>> The LOG=debug is JDK8 and build-infra specific. For JDK7 I don't know >>> of a way to get more info except adding the -d or --debug flag to >>> make, which as David says is rather useless most of the time. >>> >>> /Erik >>> >>> On 2013-02-08 00:47, Randy Nielsen wrote: >>>> >>>> Tried suggestions with no change. Specifically LOG=debug,nofile >>>> didn't add any output at all. Are there any others ways to poke the >>>> make to get more output, say a line by line trace of the make >>>> behavior? This feels like a process synchronization problem where >>>> process A is waiting to be notified by someone and of course the >>>> notify never occurs. But why would a bunch of compiles etc. use this kind of synchronization? >>>> >>>> Also I tried strace to peek under the covers, and concluded that >>>> Cygwin strace is very buggy. Details (optional) follow, after my signature. >>>> >>>> Randy >>>> >>>> I ran strace on top of the make of hotspot and to my utter >>>> astonishment after a few seconds it ended like this: >>>> >>>> $ strace make hotspot>strace.txt >>>> /bin/sh: >>>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link: >>>> Function not implemented >>>> jdk/make/common/shared/Compiler-msvc.gmk:80: *** >>>> COMPILER_VERSION cannot be empty here. Stop. >>>> >>>> Being a suspicious soul I then tried this: >>>> >>>> $ strace make sanity>trace.txt >>>> /bin/sh: >>>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link: >>>> Function not implemented >>>> jdk/make/common/shared/Compiler-msvc.gmk:80: *** >>>> COMPILER_VERSION cannot be empty here. Stop. >>>> >>>> Of course the "make sanity" without strace works perfectly. Conclusion: >>>> the Cygwin strace is buggy (big surprise) and can't be used to help >>>> peer "under the covers" of the hotspot make. >>>> >>>> >>>> -----Original Message----- >>>> From: Kelly Ohair [mailto:kelly.ohair at oracle.com] >>>> Sent: Thursday, February 07, 2013 8:36 AM >>>> To: Randy Nielsen >>>> Cc: build-dev at openjdk.java.net >>>> Subject: Re: Hang building JDK 7 Hotspot in Windows 7 >>>> >>>> no definite answers just ideas >>>> >>>> we are starting to use windows 2008R2 which seems better make sure >>>> the env vars TMP and TEMP are set to directories windows understands >>>> eg C:/ paths and these directories exist and have write permissions >>>> try using make LOG=debug,nofile >>>> >>>> >>>> Sent from my iPhone >>>> >>>> On Feb 6, 2013, at 23:59, Randy Nielsen wrote: >>>> >>>>> I am thoroughly stuck building JDK 7 when I start the Hotspot >>>>> portion of the build. This is Windows 7 64 bit building 64 bit JDK >>>>> with Visual Studio >>>>> 10 Service Pack 1. The hang seems to happen immediately after I >>>>> start the hotspot portion of the make. There is no output at all. >>>>> Watching the Windows Task Manager in the Processes tab shows the >>>>> System Idle process at 99% almost all of the time. Occasionally >>>>> mscorsvw.exe (.NET services) or minty.exe gets a few % of CPU but only very briefly. >>>>> >>>>>> From browsing the web I've tried the following "fixes": verified >>>>>> that there was no anti-virus program, and disabled ASLR (Address >>>>>> Space Layout Randomization). No change in behavior. >>>>> >>>>> Has anyone any ideas about how to deal with this? Also are there >>>>> settings in the make that will dramatically increase the level of >>>>> logging in the make that might help me debug this? >>>>> >>>>> Here's the output of the make hotspot: >>>>> >>>>> /usr/bin/mkdir -p >>>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >>>>> /usr/bin/mkdir -p >>>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>>>> >>>>> >>>>> ################################################################### >>>>> ### >>>>> ## >>>>> ######################################################################## >>>>> ##### Entering hotspot for target(s) all_product ##### >>>>> ################################################################### >>>>> ### >>>>> ## >>>>> >>>>> cd ./hotspot/make&& \ >>>>> make JDK_TOPDIR=C:/OpenJDK/openjdk/jdk >>>>> JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared >>>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >>>>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 >>>>> JDK_BUILD_NUMBER=b00 >>>>> FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 >>>>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 >>>>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 >>>>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 >>>>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 >>>>> ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" >>>>> ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/output >>>>> dir >>>>> ALT_EXPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hotspot/impo >>>>> rt ALT_SLASH_JAVA="c:/OpenJDK" ALT_BOOTDIR=c:/OpenJDK/jdk-6u18 >>>>> ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools >>>>> /di >>>>> st all_product >>>>> >>>>> ==>> That's it - no more output. >>>>> >>>>> The output of the sanity portion of the make is below. >>>>> >>>>> Hoping someone can help! >>>>> >>>>> Randy >>>>> >>>>> $ make >>>>> cygwin warning: >>>>> MS-DOS style path detected: C:/Windows/system32/wscript.exe >>>>> Preferred POSIX equivalent is: >>>>> /cygdrive/c/Windows/system32/wscript.exe >>>>> CYGWIN environment variable option "nodosfilewarning" turns off >>>>> this warning. >>>>> Consult the user's guide for more details about POSIX paths: >>>>> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames >>>>> ( cd ./jdk/make&& \ >>>>> make sanity HOTSPOT_IMPORT_CHECK=false >>>>> JDK_TOPDIR=C:/OpenJDK/openjdk/jdk >>>>> JDK_MAKE_SHARED_DIR=C:/OpenJDK/openjdk/jdk/make/common/shared >>>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >>>>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 >>>>> JDK_BUILD_NUMBER=b00 >>>>> FULL_VERSION=1.7.0-internal-administrator_2013_02_06_23_32-b00 >>>>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 >>>>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 >>>>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 >>>>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 >>>>> ANT_HOME="c:/OpenJDK/apache-ant-1.7.1" >>>>> ALT_OUTPUTDIR=C:/OpenJDK/openjdk/build/windows-amd64 >>>>> ALT_LANGTOOLS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/langtools >>>>> /di st >>>>> ALT_CORBA_DIST=C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >>>>> ALT_JAXP_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >>>>> ALT_JAXWS_DIST=C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >>>>> ALT_HOTSPOT_IMPORT_PATH=C:/OpenJDK/openjdk/build/windows-amd64/hots >>>>> pot >>>>> /import BUILD_HOTSPOT=true ; ) >>>>> make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' >>>>> make[1]: Leaving directory `/cygdrive/c/OpenJDK/openjdk/jdk/make' >>>>> >>>>> Build Machine Information: >>>>> build machine = WIN-R7HSHTAIIHC >>>>> >>>>> Build Directory Structure: >>>>> CWD = /cygdrive/c/OpenJDK/openjdk >>>>> TOPDIR = . >>>>> LANGTOOLS_TOPDIR = ./langtools >>>>> JAXP_TOPDIR = ./jaxp >>>>> JAXWS_TOPDIR = ./jaxws >>>>> CORBA_TOPDIR = ./corba >>>>> HOTSPOT_TOPDIR = ./hotspot >>>>> JDK_TOPDIR = ./jdk >>>>> >>>>> Build Directives: >>>>> BUILD_LANGTOOLS = true >>>>> BUILD_JAXP = true >>>>> BUILD_JAXWS = true >>>>> BUILD_CORBA = true >>>>> BUILD_HOTSPOT = true >>>>> BUILD_JDK = true >>>>> DEBUG_CLASSFILES = >>>>> DEBUG_BINARIES = >>>>> >>>>> Hotspot Settings: >>>>> HOTSPOT_BUILD_JOBS = >>>>> HOTSPOT_OUTPUTDIR = >>>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/outputdir >>>>> HOTSPOT_EXPORT_PATH = >>>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>>>> >>>>> >>>>> >>>>> >>>>> Bootstrap Settings: >>>>> BOOTDIR = c:/OpenJDK/jdk-6u18 >>>>> ALT_BOOTDIR = c:/OpenJDK/jdk-6u18 >>>>> BOOT_VER = 1.6.0 [requires at least 1.6] OUTPUTDIR = >>>>> C:/OpenJDK/openjdk/build/windows-amd64 >>>>> ALT_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 >>>>> ABS_OUTPUTDIR = C:/OpenJDK/openjdk/build/windows-amd64 >>>>> >>>>> Build Tool Settings: >>>>> SLASH_JAVA = c:/OpenJDK >>>>> ALT_SLASH_JAVA = c:/OpenJDK >>>>> VARIANT = OPT >>>>> JDK_DEVTOOLS_DIR = c:/OpenJDK/devtools >>>>> ALT_JDK_DEVTOOLS_DIR = >>>>> ANT_HOME = c:/OpenJDK/apache-ant-1.7.1 UNIXCOMMAND_PATH = /usr/bin/ >>>>> ALT_UNIXCOMMAND_PATH = >>>>> COMPILER_PATH = >>>>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/ >>>>> ALT_COMPILER_PATH = >>>>> DEVTOOLS_PATH = /usr/bin/ >>>>> ALT_DEVTOOLS_PATH = >>>>> MSVCRNN_DLL_PATH = >>>>> C:/PROGRA~2/MICROS~2.0/Vc/redist/x64/Microsoft.VC100.CRT >>>>> ALT_MSVCRNN_DLL_PATH = >>>>> INCLUDE = >>>>> C:/PROGRA~2/MICROS~2.0/VC/include;C:/MSSDKWIN7/Windows/v7.1/Include >>>>> LIB = >>>>> C:/PROGRA~2/MICROS~2.0/VC/lib/amd64;C:/MSSDKWIN7/Windows/v7.1/Lib/x64 >>>>> COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) >>>>> COMPILER_VERSION = VS2010 CC_VER = 16.00.40219.01 [requires at >>>>> least 16.00.30319.01] ZIP_VER = 3.0 [requires at least 2.2] >>>>> UNZIP_VER = >>>>> 6.00 [requires at least 5.12] LINK_VER = 10.00.40219.01 [requires >>>>> at least 10.00.30319.01] CC = >>>>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/cl >>>>> LINK = C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/link >>>>> DUMPBIN = >>>>> C:/PROGRA~2/MICROS~2.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe >>>>> ANT_VER = 1.7.1 [requires at least 1.7.1] TEMPDIR = >>>>> C:/OpenJDK/openjdk/build/windows-amd64/tmp >>>>> >>>>> Build Directives: >>>>> OPENJDK = true >>>>> USE_HOTSPOT_INTERPRETER_MODE = >>>>> PEDANTIC = >>>>> DEV_ONLY = >>>>> NO_DOCS = >>>>> NO_IMAGES = >>>>> TOOLS_ONLY = >>>>> INSANE = >>>>> COMPILE_APPROACH = normal >>>>> FASTDEBUG = >>>>> COMPILER_WARNINGS_FATAL = false >>>>> COMPILER_WARNING_LEVEL = 3 >>>>> SHOW_ALL_WARNINGS = false >>>>> INCREMENTAL_BUILD = false >>>>> CC_HIGHEST_OPT = >>>>> CC_HIGHER_OPT = >>>>> CC_LOWER_OPT = >>>>> CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D >>>>> _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- >>>>> -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb >>>>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 >>>>> -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >>>>> CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D >>>>> _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- >>>>> -FdC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.pdb >>>>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/obj64/.map -wd4800 >>>>> -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >>>>> BOOT_JAVA_CMD = c:/OpenJDK/jdk-6u18/bin/java -XX:-PrintVMOptions >>>>> -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m >>>>> -XX:PermSize=32m -XX:MaxPermSize=160m BOOT_JAVAC_CMD = >>>>> c:/OpenJDK/jdk-6u18/bin/javac -J-XX:ThreadStackSize=1536 >>>>> -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions >>>>> -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m >>>>> -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 >>>>> -XDignore.symbol.file=true BOOT_JAR_CMD = >>>>> c:/OpenJDK/jdk-6u18/bin/jar BOOT_JARSIGNER_CMD = >>>>> c:/OpenJDK/jdk-6u18/bin/jarsigner >>>>> >>>>> Build Platform Settings: >>>>> USER = Administrator >>>>> PLATFORM = windows >>>>> ARCH = amd64 >>>>> LIBARCH = amd64 >>>>> ARCH_FAMILY = amd64 >>>>> ARCH_DATA_MODEL = 64 >>>>> ARCHPROP = amd64 >>>>> PROCESSOR_ARCHITECTURE = x86 >>>>> PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 26 Stepping 5, >>>>> GenuineIntel USING_CYGWIN = true CYGWIN_VER = 6.1 [requires at >>>>> least 4.0] CYGPATH_CMD = cygpath -a -s -m OS_VERSION = 6.1 >>>>> [requires at least 5.2] OS_VARIANT_NAME = OS_VARIANT_VERSION = >>>>> 6.1 MB_OF_MEMORY = 8191 >>>>> >>>>> GNU Make Settings: >>>>> MAKE = make >>>>> MAKE_VER = 3.82 [requires at least 3.81] MAKECMDGOALS = sanity >>>>> MAKEFLAGS = w SHELL = /bin/sh >>>>> >>>>> Target Build Versions: >>>>> JDK_VERSION = 1.7.0 >>>>> MILESTONE = internal >>>>> RELEASE = 1.7.0-internal >>>>> FULL_VERSION = 1.7.0-internal-administrator_2013_02_06_23_32-b00 >>>>> BUILD_NUMBER = b00 >>>>> >>>>> External File/Binary Locations: >>>>> USRJDKINSTANCES_PATH = C:/PROGRA~1/Java BUILD_JDK_IMPORT_PATH = >>>>> c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries >>>>> ALT_BUILD_JDK_IMPORT_PATH = >>>>> JDK_IMPORT_PATH = >>>>> c:/OpenJDK/re/jdk/1.7.0/promoted/latest/binaries/windows-amd64 >>>>> ALT_JDK_IMPORT_PATH = >>>>> LANGTOOLS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist >>>>> ALT_LANGTOOLS_DIST = >>>>> C:/OpenJDK/openjdk/build/windows-amd64/langtools/dist >>>>> CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >>>>> ALT_CORBA_DIST = C:/OpenJDK/openjdk/build/windows-amd64/corba/dist >>>>> JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >>>>> ALT_JAXP_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxp/dist >>>>> JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >>>>> ALT_JAXWS_DIST = C:/OpenJDK/openjdk/build/windows-amd64/jaxws/dist >>>>> HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR >>>>> ALT_HOTSPOT_DOCS_IMPORT_PATH = >>>>> HOTSPOT_IMPORT_PATH = >>>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>>>> ALT_HOTSPOT_IMPORT_PATH = >>>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import >>>>> HOTSPOT_SERVER_PATH = >>>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/jre/bin/server >>>>> ALT_HOTSPOT_SERVER_PATH = >>>>> HOTSPOT_LIB_PATH = >>>>> C:/OpenJDK/openjdk/build/windows-amd64/hotspot/import/lib >>>>> ALT_HOTSPOT_LIB_PATH = >>>>> DXSDK_VER = 0x0900 >>>>> DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 >>>>> ALT_DXSDK_PATH = C:/PROGRA~2/MI4ADD~1 DXSDK_INCLUDE_PATH = >>>>> C:/PROGRA~2/MI4ADD~1/Include >>>>> ALT_DXSDK_INCLUDE_PATH = >>>>> DXSDK_LIB_PATH = C:/PROGRA~2/MI4ADD~1/Lib/x64 >>>>> ALT_DXSDK_LIB_PATH = >>>>> WINDOWSSDKDIR = C:/PROGRA~2/MICROS~1/Windows/v7.0a/ >>>>> ALT_WINDOWSSDKDIR = >>>>> RC = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/RC.Exe >>>>> REBASE = C:/PROGRA~2/MICROS~1/Windows/v7.0a//Bin/x64/ReBase.Exe >>>>> CACERTS_FILE = ./../src/share/lib/security/cacerts >>>>> ALT_CACERTS_FILE = >>>>> >>>>> OpenJDK-specific settings: >>>>> FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include >>>>> ALT_FREETYPE_HEADERS_PATH = C:/OpenJDK/freetype-2.4.11/include >>>>> FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 >>>>> ALT_FREETYPE_LIB_PATH = C:/OpenJDK/freetype-2.4.11 >>>>> >>>>> Previous JDK Settings: >>>>> PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE >>>>> ALT_PREVIOUS_RELEASE_PATH = >>>>> PREVIOUS_JDK_VERSION = 1.6.0 >>>>> ALT_PREVIOUS_JDK_VERSION = >>>>> PREVIOUS_JDK_FILE = >>>>> ALT_PREVIOUS_JDK_FILE = >>>>> PREVIOUS_JRE_FILE = >>>>> ALT_PREVIOUS_JRE_FILE = >>>>> PREVIOUS_RELEASE_IMAGE = c:/OpenJDK/jdk-6u18 >>>>> ALT_PREVIOUS_RELEASE_IMAGE = >>>>> >>>>> >>>>> WARNING: To build Java 2 SDK 1.7.0 you need : >>>>> VS2010 - link.exe version '10.00.30319.01' >>>>> Specifically the Visual Studio 10 link.exe. >>>>> You appear to be using Linker version '10.00.40219.01' >>>>> >>>>> Sanity check passed. >>>>> make \ >>>>> SKIP_FASTDEBUG_BUILD=true \ >>>>> SKIP_DEBUG_BUILD=true \ >>>>> \ >>>>> generic_build_repo_series >>>>> make[1]: Entering directory `/cygdrive/c/OpenJDK/openjdk' >>>>> /usr/bin/mkdir -p ./build/windows-amd64/j2sdk-image /usr/bin/mkdir >>>>> -p C:/OpenJDK/openjdk/build/windows-amd64/langtools >>>>> >>>>> == End of listing of make sanity portion of build == >>>>> >>>>> >> >> From david.katleman at oracle.com Mon Feb 11 22:42:07 2013 From: david.katleman at oracle.com (David Katleman) Date: Mon, 11 Feb 2013 14:42:07 -0800 Subject: sjavac in jdk 8 builds In-Reply-To: <9BB2AEBF-3C31-44A1-876B-E1179B1E9700@oracle.com> References: <201302010116.r111G3cV006706@rehudson.us.oracle.com> <9BB2AEBF-3C31-44A1-876B-E1179B1E9700@oracle.com> Message-ID: <511973BF.8020800@oracle.com> On 2/11/2013 1:56 PM, Vita Santrucek wrote: > I see that sjavac was pushed in b75: > > but in our logs we seem to disable it: > > ? > checking whether to use sjavac? no > ... > [3] DISABLE_SJAVAC:=true > ... > > Why don't we use it when building JDK 8? It's not that we disable it, autoconf does that for any build, by default. Including Fredrik for insight on why it's not on by default, or an expectation of when it will. > checking for memory size... 3042 MB > checking whether to use sjavac... no > checking that precompiled headers work... yes If I'm reading the feature right, you have to explicitly add "--enable-sjavac" to your build options > It is not available in the final image. Thus to use it, you have to compile the OpenJDK yourself. > The new build system makes use of it, if you add --enable-sjavac to the configure arguments. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004658 Dave From erik.joelsson at oracle.com Tue Feb 12 07:28:47 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 12 Feb 2013 08:28:47 +0100 Subject: sjavac in jdk 8 builds In-Reply-To: <511973BF.8020800@oracle.com> References: <201302010116.r111G3cV006706@rehudson.us.oracle.com> <9BB2AEBF-3C31-44A1-876B-E1179B1E9700@oracle.com> <511973BF.8020800@oracle.com> Message-ID: <5119EF2F.4000802@oracle.com> What David says is correct. We hope to enable it by default soon, but feel that it could use some hardening first. /Erik On 2013-02-11 23:42, David Katleman wrote: > On 2/11/2013 1:56 PM, Vita Santrucek wrote: >> I see that sjavac was pushed in b75: >> >> but in our logs we seem to disable it: >> >> ? >> checking whether to use sjavac? no >> ... >> [3] DISABLE_SJAVAC:=true >> ... >> >> Why don't we use it when building JDK 8? > > It's not that we disable it, autoconf does that for any build, by > default. > > Including Fredrik for insight on why it's not on by default, or an > expectation of when it will. > >> checking for memory size... 3042 MB >> checking whether to use sjavac... no >> checking that precompiled headers work... yes > > If I'm reading the feature right, you have to explicitly add > "--enable-sjavac" to your build options > >> It is not available in the final image. Thus to use it, you have to >> compile the OpenJDK yourself. >> The new build system makes use of it, if you add --enable-sjavac to >> the configure arguments. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004658 > > Dave > > From kelly.ohair at oracle.com Tue Feb 12 19:11:03 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 12 Feb 2013 11:11:03 -0800 Subject: build JDK 7 Windows 7: make jdk fails building sounds In-Reply-To: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> References: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> Message-ID: It is my understanding that this is why we require the use of a specific DirectX SDK. http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#dxsdk -kto On Feb 8, 2013, at 7:07 PM, Randy Nielsen wrote: > "make jdk" fails building JavaX Sounds library in the include file objidl.h. Output is below. The compiler fails trying to use this: "__RPC__out_xcount_part". The web suggests that the fix is obtained by placing your SDK entries before your VC entries in the PATH and the LIB. I've done this but failure is the same. Does anyone have any suggestions? > > Randy > > Building lib:C:/OpenJDK/openjdk/build/windows-amd64/bin/jsoundds.dll > "C:/PROGRA~2/MICROS~2.0/Common7/Tools"/../../Vc/bin/amd64/cl -O1 -Zi -nologo -M > D /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -FdC:/OpenJ > DK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_W > inOS_DirectSound.pdb -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sou > nd/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 -D _CRT_SECURE_ > NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE -DNDEBUG -DWIN32 -DIAL -D_LITTLE_END > IAN -D_AMD64_ -Damd64 -DWIN32_LEAN_AND_MEAN -I. -IC:/OpenJDK/openjdk/build/windo > ws-amd64/tmp/sun/javax.sound/jsoundds/CClassHeaders -I../../../../src/windows/ja > vavm/export -I../../../../src/share/javavm/export -I../../../../src/share/native > /common -I../../../../src/windows/native/common -I../../../../src/share/native/j > avax/sound -I../../../../src/windows/native/javax/sound -DX_PLATFORM=X_WINDOWS > -DX_ARCH=X_AMD64 -DUSE_DAUDIO=TRUE -I../../../../src/share/native/com/sun/media > /sound -IC:/PROGRA~2/MI4ADD~1/Include -c -FoC:/OpenJDK/openjdk/build/windows-am > d64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.obj ../.. > /../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_DirectSound.cpp > > PLATFORM_API_WinOS_DirectSound.cpp > C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11280) : error C2061: syntax error : > identifier '__RPC__out_xcount_part' > C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : error C2059: syntax error : > ')' > C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : fatal error C1903: unable to > recover from previous error(s); stopping compilation > make[4]: *** [C:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundd > s/obj64/PLATFORM_API_WinOS_DirectSound.obj] Error 2 > make[4]: Leaving directory `/cygdrive/c/OpenJDK/openjdk/jdk/make/javax/sound/jso From rnielsen at vocera.com Tue Feb 12 19:25:24 2013 From: rnielsen at vocera.com (Randy Nielsen) Date: Tue, 12 Feb 2013 11:25:24 -0800 Subject: build JDK 7 Windows 7: make jdk fails building sounds In-Reply-To: References: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> Message-ID: <1AC3281AD57A34468B9879C754022CAF05F1556C9D@exchange.vocera.local> Actually I think this failure is because I accidentally installed two different versions of the windows 7 sdk. I've rebuilt my system and am starting the build again. The OpenJDK README does require a specific version of DirectX 9 SDK - the Summer 2004 version. The *problem* is that the Summer 2004 build is not available anywhere - at least I couldn't find it. I settled for August 2006 build, which was the closest I could find. If you or anyone could point me at a link with the 2004 build I'd be grateful. For Windows at least the OpenJDK build seems to me to be fraught with difficulties in getting the correct version of tools that work together. Most notable are some Microsoft products (DirectX) and recent versions of Cygwin hanging building Hotspot. The almost impossibility of clean uninstalls of Microsoft products adds to the difficulties here. I'm not sure anything can be done about this, at least for a make system for JDK 7 that is clearly long in the tooth. Do you think that the JDK8 build system will be sturdier with Windows? Regards, Randy -----Original Message----- From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] Sent: Tuesday, February 12, 2013 11:11 AM To: Randy Nielsen Cc: build-dev at openjdk.java.net Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds It is my understanding that this is why we require the use of a specific DirectX SDK. http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#dxsdk -kto On Feb 8, 2013, at 7:07 PM, Randy Nielsen wrote: > "make jdk" fails building JavaX Sounds library in the include file objidl.h. Output is below. The compiler fails trying to use this: "__RPC__out_xcount_part". The web suggests that the fix is obtained by placing your SDK entries before your VC entries in the PATH and the LIB. I've done this but failure is the same. Does anyone have any suggestions? > > Randy > > Building lib:C:/OpenJDK/openjdk/build/windows-amd64/bin/jsoundds.dll > "C:/PROGRA~2/MICROS~2.0/Common7/Tools"/../../Vc/bin/amd64/cl -O1 -Zi > -nologo -M D /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB > -Zc:wchar_t- -FdC:/OpenJ > DK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundds/obj64/PLAT > FORM_API_W inOS_DirectSound.pdb > -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sou > nd/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 -D _CRT_SECURE_ > NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE -DNDEBUG -DWIN32 -DIAL -D_LITTLE_END > IAN -D_AMD64_ -Damd64 -DWIN32_LEAN_AND_MEAN -I. > -IC:/OpenJDK/openjdk/build/windo > ws-amd64/tmp/sun/javax.sound/jsoundds/CClassHeaders > -I../../../../src/windows/ja vavm/export -I../../../../src/share/javavm/export -I../../../../src/share/native /common -I../../../../src/windows/native/common -I../../../../src/share/native/j > avax/sound -I../../../../src/windows/native/javax/sound -DX_PLATFORM=X_WINDOWS > -DX_ARCH=X_AMD64 -DUSE_DAUDIO=TRUE > -I../../../../src/share/native/com/sun/media > /sound -IC:/PROGRA~2/MI4ADD~1/Include -c > -FoC:/OpenJDK/openjdk/build/windows-am > d64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.obj ../.. > /../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_Direc > tSound.cpp > > PLATFORM_API_WinOS_DirectSound.cpp > C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11280) : error C2061: syntax error : > identifier '__RPC__out_xcount_part' > C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : error C2059: syntax error : > ')' > C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : fatal error C1903: > unable to recover from previous error(s); stopping compilation > make[4]: *** > [C:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundd > s/obj64/PLATFORM_API_WinOS_DirectSound.obj] Error 2 > make[4]: Leaving directory > `/cygdrive/c/OpenJDK/openjdk/jdk/make/javax/sound/jso From philip.race at oracle.com Tue Feb 12 19:41:40 2013 From: philip.race at oracle.com (Phil Race) Date: Tue, 12 Feb 2013 11:41:40 -0800 Subject: build JDK 7 Windows 7: make jdk fails building sounds In-Reply-To: <1AC3281AD57A34468B9879C754022CAF05F1556C9D@exchange.vocera.local> References: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> <1AC3281AD57A34468B9879C754022CAF05F1556C9D@exchange.vocera.local> Message-ID: <511A9AF4.60300@oracle.com> I think Microsoft may have recently removed this. Typing "summer 2004 direct x sdk" into google, the top hit is a link to the download location but it is no longer is a valid link. Obviously lots of people already have a copy but I'm not sure if they can redistribute it to you. We specified that one because versions before and afterward were unstable. At least that is what our engineer working on the Direct X pipeline for JDK 6u10 told me. If its no longer available we may need to look into testing a much newer version. June 2010 as we use in FX might be a safe bet. -phil. On 2/12/2013 11:25 AM, Randy Nielsen wrote: > Actually I think this failure is because I accidentally installed two different versions of the windows 7 sdk. I've rebuilt my system and am starting the build again. > > The OpenJDK README does require a specific version of DirectX 9 SDK - the Summer 2004 version. The *problem* is that the Summer 2004 build is not available anywhere - at least I couldn't find it. I settled for August 2006 build, which was the closest I could find. If you or anyone could point me at a link with the 2004 build I'd be grateful. > > For Windows at least the OpenJDK build seems to me to be fraught with difficulties in getting the correct version of tools that work together. Most notable are some Microsoft products (DirectX) and recent versions of Cygwin hanging building Hotspot. The almost impossibility of clean uninstalls of Microsoft products adds to the difficulties here. I'm not sure anything can be done about this, at least for a make system for JDK 7 that is clearly long in the tooth. > > Do you think that the JDK8 build system will be sturdier with Windows? > > Regards, > > Randy > > -----Original Message----- > From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] > Sent: Tuesday, February 12, 2013 11:11 AM > To: Randy Nielsen > Cc: build-dev at openjdk.java.net > Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds > > It is my understanding that this is why we require the use of a specific DirectX SDK. > http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#dxsdk > > -kto > > > On Feb 8, 2013, at 7:07 PM, Randy Nielsen wrote: > >> "make jdk" fails building JavaX Sounds library in the include file objidl.h. Output is below. The compiler fails trying to use this: "__RPC__out_xcount_part". The web suggests that the fix is obtained by placing your SDK entries before your VC entries in the PATH and the LIB. I've done this but failure is the same. Does anyone have any suggestions? >> >> Randy >> >> Building lib:C:/OpenJDK/openjdk/build/windows-amd64/bin/jsoundds.dll >> "C:/PROGRA~2/MICROS~2.0/Common7/Tools"/../../Vc/bin/amd64/cl -O1 -Zi >> -nologo -M D /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB >> -Zc:wchar_t- -FdC:/OpenJ >> DK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundds/obj64/PLAT >> FORM_API_W inOS_DirectSound.pdb >> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sou >> nd/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 -D _CRT_SECURE_ >> NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE -DNDEBUG -DWIN32 -DIAL -D_LITTLE_END >> IAN -D_AMD64_ -Damd64 -DWIN32_LEAN_AND_MEAN -I. >> -IC:/OpenJDK/openjdk/build/windo >> ws-amd64/tmp/sun/javax.sound/jsoundds/CClassHeaders >> -I../../../../src/windows/ja vavm/export -I../../../../src/share/javavm/export -I../../../../src/share/native /common -I../../../../src/windows/native/common -I../../../../src/share/native/j >> avax/sound -I../../../../src/windows/native/javax/sound -DX_PLATFORM=X_WINDOWS >> -DX_ARCH=X_AMD64 -DUSE_DAUDIO=TRUE >> -I../../../../src/share/native/com/sun/media >> /sound -IC:/PROGRA~2/MI4ADD~1/Include -c >> -FoC:/OpenJDK/openjdk/build/windows-am >> d64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.obj ../.. >> /../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_Direc >> tSound.cpp >> >> PLATFORM_API_WinOS_DirectSound.cpp >> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11280) : error C2061: syntax error : >> identifier '__RPC__out_xcount_part' >> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : error C2059: syntax error : >> ')' >> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : fatal error C1903: >> unable to recover from previous error(s); stopping compilation >> make[4]: *** >> [C:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundd >> s/obj64/PLATFORM_API_WinOS_DirectSound.obj] Error 2 >> make[4]: Leaving directory >> `/cygdrive/c/OpenJDK/openjdk/jdk/make/javax/sound/jso From david.katleman at oracle.com Wed Feb 13 00:42:58 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 13 Feb 2013 00:42:58 +0000 Subject: hg: jdk8/build: Added tag jdk8-b76 for changeset 278af9fc67e7 Message-ID: <20130213004259.1481C479F8@hg.openjdk.java.net> Changeset: 3933eebc659d Author: katleman Date: 2013-02-07 12:32 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/3933eebc659d Added tag jdk8-b76 for changeset 278af9fc67e7 ! .hgtags From david.katleman at oracle.com Wed Feb 13 00:43:02 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 13 Feb 2013 00:43:02 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b76 for changeset 58be6ca3c060 Message-ID: <20130213004304.0BD60479F9@hg.openjdk.java.net> Changeset: 35684a40c584 Author: katleman Date: 2013-02-07 12:32 -0800 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/35684a40c584 Added tag jdk8-b76 for changeset 58be6ca3c060 ! .hgtags From rnielsen at vocera.com Wed Feb 13 00:43:45 2013 From: rnielsen at vocera.com (Randy Nielsen) Date: Tue, 12 Feb 2013 16:43:45 -0800 Subject: build JDK 7 Windows 7: make jdk fails building sounds In-Reply-To: <511A9AF4.60300@oracle.com> References: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> <1AC3281AD57A34468B9879C754022CAF05F1556C9D@exchange.vocera.local> <511A9AF4.60300@oracle.com> Message-ID: <1AC3281AD57A34468B9879C754022CAF05F1556F14@exchange.vocera.local> Building with DirectX 9 publicly available builds from 2006, the closest I can find to 2004, fails. However with access to a DirectX 9 build only available on MSDN with a login I found a DirectX version from October 2004: dxsdk_oct2004.exe. When I installed this I was finally able to successfully build OpenJDK JDK 7. About time! Unfortunately I can't redistribute this file, but it is available through MSDN. Regards, Randy -----Original Message----- From: Phil Race [mailto:philip.race at oracle.com] Sent: Tuesday, February 12, 2013 11:42 AM To: Randy Nielsen Cc: Kelly O'Hair; build-dev at openjdk.java.net Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds I think Microsoft may have recently removed this. Typing "summer 2004 direct x sdk" into google, the top hit is a link to the download location but it is no longer is a valid link. Obviously lots of people already have a copy but I'm not sure if they can redistribute it to you. We specified that one because versions before and afterward were unstable. At least that is what our engineer working on the Direct X pipeline for JDK 6u10 told me. If its no longer available we may need to look into testing a much newer version. June 2010 as we use in FX might be a safe bet. -phil. On 2/12/2013 11:25 AM, Randy Nielsen wrote: > Actually I think this failure is because I accidentally installed two different versions of the windows 7 sdk. I've rebuilt my system and am starting the build again. > > The OpenJDK README does require a specific version of DirectX 9 SDK - the Summer 2004 version. The *problem* is that the Summer 2004 build is not available anywhere - at least I couldn't find it. I settled for August 2006 build, which was the closest I could find. If you or anyone could point me at a link with the 2004 build I'd be grateful. > > For Windows at least the OpenJDK build seems to me to be fraught with difficulties in getting the correct version of tools that work together. Most notable are some Microsoft products (DirectX) and recent versions of Cygwin hanging building Hotspot. The almost impossibility of clean uninstalls of Microsoft products adds to the difficulties here. I'm not sure anything can be done about this, at least for a make system for JDK 7 that is clearly long in the tooth. > > Do you think that the JDK8 build system will be sturdier with Windows? > > Regards, > > Randy > > -----Original Message----- > From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] > Sent: Tuesday, February 12, 2013 11:11 AM > To: Randy Nielsen > Cc: build-dev at openjdk.java.net > Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds > > It is my understanding that this is why we require the use of a specific DirectX SDK. > http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html# > dxsdk > > -kto > > > On Feb 8, 2013, at 7:07 PM, Randy Nielsen wrote: > >> "make jdk" fails building JavaX Sounds library in the include file objidl.h. Output is below. The compiler fails trying to use this: "__RPC__out_xcount_part". The web suggests that the fix is obtained by placing your SDK entries before your VC entries in the PATH and the LIB. I've done this but failure is the same. Does anyone have any suggestions? >> >> Randy >> >> Building lib:C:/OpenJDK/openjdk/build/windows-amd64/bin/jsoundds.dll >> "C:/PROGRA~2/MICROS~2.0/Common7/Tools"/../../Vc/bin/amd64/cl -O1 -Zi >> -nologo -M D /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB >> -Zc:wchar_t- -FdC:/OpenJ >> DK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundds/obj64/PLA >> T >> FORM_API_W inOS_DirectSound.pdb >> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sou >> nd/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 -D _CRT_SECURE_ >> NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE -DNDEBUG -DWIN32 -DIAL -D_LITTLE_END >> IAN -D_AMD64_ -Damd64 -DWIN32_LEAN_AND_MEAN -I. >> -IC:/OpenJDK/openjdk/build/windo >> ws-amd64/tmp/sun/javax.sound/jsoundds/CClassHeaders >> -I../../../../src/windows/ja vavm/export -I../../../../src/share/javavm/export -I../../../../src/share/native /common -I../../../../src/windows/native/common -I../../../../src/share/native/j >> avax/sound -I../../../../src/windows/native/javax/sound -DX_PLATFORM=X_WINDOWS >> -DX_ARCH=X_AMD64 -DUSE_DAUDIO=TRUE >> -I../../../../src/share/native/com/sun/media >> /sound -IC:/PROGRA~2/MI4ADD~1/Include -c >> -FoC:/OpenJDK/openjdk/build/windows-am >> d64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.obj ../.. >> /../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_Dire >> c >> tSound.cpp >> >> PLATFORM_API_WinOS_DirectSound.cpp >> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11280) : error C2061: syntax error : >> identifier '__RPC__out_xcount_part' >> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : error C2059: syntax error : >> ')' >> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : fatal error C1903: >> unable to recover from previous error(s); stopping compilation >> make[4]: *** >> [C:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundd >> s/obj64/PLATFORM_API_WinOS_DirectSound.obj] Error 2 >> make[4]: Leaving directory >> `/cygdrive/c/OpenJDK/openjdk/jdk/make/javax/sound/jso From david.katleman at oracle.com Wed Feb 13 00:45:20 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 13 Feb 2013 00:45:20 +0000 Subject: hg: jdk8/build/hotspot: 74 new changesets Message-ID: <20130213004740.BC43A479FA@hg.openjdk.java.net> Changeset: da53cb17186a Author: katleman Date: 2013-02-07 12:32 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/da53cb17186a Added tag jdk8-b76 for changeset 20b605466ccb ! .hgtags Changeset: 6fbe8a57549d Author: amurillo Date: 2013-01-25 03:03 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6fbe8a57549d 8006827: new hotspot build - hs25-b18 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3c327c2b6782 Author: jmasa Date: 2013-01-03 15:03 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3c327c2b6782 8004895: NPG: JMapPermCore test failure caused by warnings about missing field Reviewed-by: johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ef1e11845e18 Author: jmasa Date: 2013-02-04 12:01 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ef1e11845e18 Merge ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5daaddd917a1 Author: coleenp Date: 2013-01-23 10:34 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5daaddd917a1 8006040: NPG: on_stack processing wastes space in ConstantPool Summary: Added on_stack bit to flags. Also MetadataMarkOnStack is used for more than JVMTI so had to be moved. Reviewed-by: dholmes, stefank ! src/share/vm/classfile/classLoaderData.cpp + src/share/vm/classfile/metadataOnStackMark.cpp + src/share/vm/classfile/metadataOnStackMark.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: 6cf2530f7fd3 Author: minqi Date: 2013-01-24 23:30 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6cf2530f7fd3 8005278: Serviceability Agent: jmap -heap and jstack -m fail Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. Reviewed-by: dholmes, sla, coleenp Contributed-by: yunda.mly at taobao.com + agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Changeset: 8b46b0196eb0 Author: zgu Date: 2013-01-25 10:04 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8b46b0196eb0 8000692: Remove old KERNEL code Summary: Removed depreciated kernel VM source code from hotspot VM Reviewed-by: dholmes, acorn ! make/Makefile ! make/bsd/makefiles/dtrace.make ! make/solaris/Makefile ! make/solaris/makefiles/dtrace.make - make/solaris/makefiles/kernel.make ! make/windows/build.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/defs.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.hpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExtensions.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiRawMonitor.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/attachListener.hpp Changeset: edd76a5856f7 Author: sspitsyn Date: 2013-01-24 22:13 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/edd76a5856f7 8005128: JSR 292: the mlvm redefineClassInBootstrap test crashes in ConstantPool::compare_entry_to Summary: When constant pool is copied in merge_constant_pools the invokedynamic operands must be copied before. Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4a0dd3799a44 Author: minqi Date: 2013-01-25 04:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4a0dd3799a44 Merge Changeset: 8d1fb417a42d Author: minqi Date: 2013-01-25 13:47 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8d1fb417a42d Merge ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: cf8470eaf7e5 Author: acorn Date: 2013-01-27 21:58 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/cf8470eaf7e5 Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: 16fb9f942703 Author: acorn Date: 2013-01-25 15:06 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/16fb9f942703 6479360: PrintClassHistogram improvements Summary: jcmd GC.class_stats (UnlockDiagnosticVMOptions) Reviewed-by: coleenp, hseigel, sla, acorn Contributed-by: ioi.lam at oracle.com ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: 0d26ce8e9251 Author: acorn Date: 2013-01-28 10:34 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0d26ce8e9251 Merge - make/solaris/makefiles/kernel.make ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp Changeset: 815957d0203e Author: acorn Date: 2013-01-28 10:55 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/815957d0203e 8004967: Default method cause VerifyError: Illegal use of nonvirtual Summary: Recognize VM generated method in old verifier Reviewed-by: acorn, coleenp Contributed-by: bharadwaj.yadavelli at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 7885e162c30f Author: acorn Date: 2013-01-28 09:33 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7885e162c30f Merge Changeset: 9be6cde7919d Author: ctornqvi Date: 2013-01-25 10:14 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9be6cde7919d 8006413: Add utility classes for writing better multiprocess tests in jtreg Summary: Add a few utility classes to test/testlibrary to support multi process testing in jtreg tests. Added a test case for one of the utility classes. Also reviewed by Vitaly Davidovich Reviewed-by: brutisso, dholmes, vlivanov, nloodin, mgerdin + test/testlibrary/OutputAnalyzerTest.java + test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java + test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java + test/testlibrary/com/oracle/java/testlibrary/OutputBuffer.java + test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java + test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java Changeset: baf7fac3167e Author: hseigel Date: 2013-02-01 14:14 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/baf7fac3167e 8006298: Specifying malformed JFR options (-XX:+FlightRecorderOptions) outputs non-sensical error Summary: Change error messages for malformed options so the messages are more useful. Reviewed-by: mikael, kvn, nloodin ! src/share/vm/runtime/arguments.cpp Changeset: 4c75576d18d0 Author: hseigel Date: 2013-02-01 13:30 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4c75576d18d0 Merge Changeset: 9bf5f643d1cf Author: sspitsyn Date: 2013-01-31 20:07 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9bf5f643d1cf 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds Summary: Need a support for invokedynamic entry kinds when new and old constant pools are merged. Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: dc31f560d6e7 Author: sspitsyn Date: 2013-01-31 20:09 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/dc31f560d6e7 8006546: JSR 292: typos in the ConstantPool::copy_cp_impl() Summary: Simple typos that need to be fixed Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/constantPool.cpp Changeset: 79c1bb8fce5d Author: sspitsyn Date: 2013-01-31 20:11 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/79c1bb8fce5d 8006731: JSR 292: the VM_RedefineClasses::rewrite_cp_refs_in_method() must support invokedynamic Summary: The invokedynamic bytecode ref to a CP entry needs to be checked and fixed as well. Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 9a9f870325cf Author: minqi Date: 2013-02-01 10:57 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9a9f870325cf Merge Changeset: b935589d2807 Author: minqi Date: 2013-02-01 14:42 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b935589d2807 Merge Changeset: 44c5fcd9cb25 Author: iklam Date: 2013-01-24 10:57 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/44c5fcd9cb25 8006280: Need to reorder metadata structures to reduce size (64-bit) Summary: Reordered Klass, InstanceKlass and Method to save 8 bytes each Reviewed-by: coleenp, jiangli Contributed-by: ioi.lam at oracle.com ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.hpp Changeset: 1eae78177059 Author: jiangli Date: 2013-02-01 15:25 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1eae78177059 Merge - make/solaris/makefiles/kernel.make ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.hpp Changeset: dc8ad3fd7050 Author: jiangli Date: 2013-02-01 19:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/dc8ad3fd7050 Merge Changeset: 4102b59539ce Author: ctornqvi Date: 2013-02-01 23:48 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4102b59539ce 8005012: Add WB APIs to better support NMT testing Summary: Add WB API functions to enable better NMT testing Reviewed-by: dholmes, zgu ! src/share/tools/whitebox/sun/hotspot/WhiteBox.java ! src/share/vm/memory/allocation.hpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 4460acf8687b Author: ctornqvi Date: 2013-02-02 07:24 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4460acf8687b Merge Changeset: 9fe95b01ad32 Author: ctornqvi Date: 2013-02-02 08:46 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9fe95b01ad32 Merge Changeset: 43badbe2717a Author: minqi Date: 2013-01-31 17:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/43badbe2717a 8000973: SA on windows thread inspection is broken Summary: After bug 7161732, On Windows SA could not find correct address of thread_id of OSThread since _thread_id moved to end of the class . The presupposition of the address is following thread handle no longer stands. Fix by adding thread_id field to OSThread and getting the address directly from OSThread. Reviewed-by: nloodin, sspitsyn Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/amd64/WindbgAMD64Thread.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/x86/WindbgX86Thread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/OSThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_amd64/Win32AMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_x86/Win32X86JavaThreadPDAccess.java Changeset: 65b632b77a97 Author: minqi Date: 2013-02-01 22:41 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/65b632b77a97 Merge Changeset: ff5401ad5635 Author: minqi Date: 2013-02-02 03:51 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ff5401ad5635 Merge Changeset: 879c6de913d6 Author: ctornqvi Date: 2013-02-02 16:34 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/879c6de913d6 8005013: Add NMT tests Summary: Add tests for the Native Memory Tracking feature, includes regression tests for 8005936 and 8004802 Reviewed-by: zgu, coleenp ! test/TEST.ROOT + test/runtime/NMT/AllocTestType.java + test/runtime/NMT/BaselineWithParameter.java + test/runtime/NMT/CommandLineDetail.java + test/runtime/NMT/CommandLineEmptyArgument.java + test/runtime/NMT/CommandLineInvalidArgument.java + test/runtime/NMT/CommandLineSummary.java + test/runtime/NMT/CommandLineTurnOffNMT.java + test/runtime/NMT/JcmdScale.java + test/runtime/NMT/JcmdWithNMTDisabled.java + test/runtime/NMT/PrintNMTStatistics.java + test/runtime/NMT/PrintNMTStatisticsWithNMTDisabled.java + test/runtime/NMT/ShutdownTwice.java + test/runtime/NMT/SummaryAfterShutdown.java + test/runtime/NMT/SummarySanityCheck.java Changeset: a7f9a1195d86 Author: ctornqvi Date: 2013-02-02 20:13 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a7f9a1195d86 8000363: runtime/7158988/FieldMonitor.java fails with exception Summary: Removed unnecessary shell script in the test. Reviewed-by: coleenp, sla ! test/runtime/7158988/FieldMonitor.java - test/runtime/7158988/TestFieldMonitor.sh Changeset: 8f696cf1a0fb Author: dsamersoff Date: 2013-02-03 22:28 +0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8f696cf1a0fb 8002048: Protocol to discovery of manageable Java processes on a network Summary: Introduce a protocol to discover manageble Java instances across a network subnet, JDP Reviewed-by: sla, dfuchs ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: c4ef3380a70b Author: hseigel Date: 2013-02-03 16:49 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c4ef3380a70b 7197672: There are issues with shared data on windows Summary: On Windows, set rw protection on the CDS file just before removing it. Reviewed-by: dcubed, iklam ! src/share/vm/memory/filemap.cpp Changeset: ce5467120c84 Author: hseigel Date: 2013-02-03 17:12 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ce5467120c84 Merge Changeset: 10d5f25a7c67 Author: hseigel Date: 2013-02-04 08:26 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/10d5f25a7c67 8000968: NPG: UseCompressedKlassPointers asserts with ObjectAlignmentInBytes for > 32G CompressedOops Summary: Pick a base that works for both CompressedOpps alignment and CompressedKlassPtrs alignment. Reviewed-by: kvn, roland ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/runtime/arguments.cpp + test/runtime/8000968/Test8000968.sh Changeset: 24a91505f9d5 Author: emc Date: 2013-02-04 13:05 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/24a91505f9d5 8006949: Update hotspot for MethodParameters format change 8006907: Hotspot should reject classfiles with multiple MethodParameters attributes Summary: Update to Hotspot's processing of MethodParameters attributes in classfiles Reviewed-by: coleenp, jrose ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/prims/jvm.cpp Changeset: 42ea5e1fad75 Author: coleenp Date: 2013-02-04 13:51 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/42ea5e1fad75 Merge Changeset: ab826603e572 Author: simonis Date: 2013-02-04 13:14 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ab826603e572 8007475: Memory stomp with UseMallocOnly Summary: Fix off-by-one error Reviewed-by: coleenp, hseigel ! src/share/vm/classfile/stackMapFrame.hpp + test/runtime/8007475/StackMapFrameTest.java Changeset: a401757763f9 Author: coleenp Date: 2013-02-04 22:59 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a401757763f9 Merge Changeset: 12285410684f Author: dholmes Date: 2013-02-04 23:53 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/12285410684f 8006508: Wrong frame constructor is called in os_linux_x86.cpp Reviewed-by: dholmes, coleenp Contributed-by: Jeremy Manson ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp Changeset: f3ea1af9207a Author: dholmes Date: 2013-02-05 00:59 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f3ea1af9207a Merge Changeset: 454d7cc622ab Author: dcubed Date: 2013-02-06 15:22 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/454d7cc622ab Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp - test/runtime/7158988/TestFieldMonitor.sh Changeset: fcc9e7681d63 Author: vlivanov Date: 2013-02-01 02:50 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fcc9e7681d63 8006410: allocating without ResourceMark when CompileCommand was specified Reviewed-by: kvn, vlivanov Contributed-by: Igor Ignatyev ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/oops/symbol.cpp Changeset: 60bba1398c51 Author: vlivanov Date: 2013-02-01 03:02 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/60bba1398c51 8005439: no message about inline method if it specifed by CompileCommand Reviewed-by: kvn, vlivanov Contributed-by: Igor Ignatyev ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: e4bb0bda20a4 Author: morris Date: 2013-01-25 16:31 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e4bb0bda20a4 8005811: Turn off TierdCompilation in JDK8 trunk for all platforms Summary: Disable tiered compilation in jdk8 because of CodeCache and performance anomalies Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp Changeset: 76341426b645 Author: drchase Date: 2013-01-25 16:09 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/76341426b645 8006500: compiler/8004741/Test8004741.java fails intermediately Summary: rewrote the test to be more reliable, add test for invalid size exception Reviewed-by: kvn ! test/compiler/8004741/Test8004741.java Changeset: 9fae07c31641 Author: morris Date: 2013-01-25 16:50 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9fae07c31641 6518907: cleanup IA64 specific code in Hotspot Summary: removed unused IA64 specific code Reviewed-by: twisti, kvn, dholmes ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/libproc.h ! agent/src/os/win32/windbg/sawindbg.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/vframeArray.cpp Changeset: 37c18711a0df Author: roland Date: 2013-02-04 09:11 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/37c18711a0df 8005114: VM is crashing in ciKlass*ciObjArrayKlass::element_klass() if metaspaces are full Summary: missing test for loaded klass in c1 Reviewed-by: kvn ! src/share/vm/c1/c1_Instruction.cpp Changeset: 39901f2f1abe Author: mikael Date: 2013-02-04 10:28 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/39901f2f1abe 8007403: Incorrect format arguments in adlparse.cpp Reviewed-by: kvn, twisti ! src/share/vm/adlc/adlparse.cpp Changeset: 8bd61471a109 Author: roland Date: 2013-02-04 11:30 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8bd61471a109 8007144: Incremental inlining mistakes some call sites for dead ones and doesn't inline them Summary: wrong detection for dead call sites. Reviewed-by: kvn ! src/share/vm/opto/callGenerator.cpp Changeset: 6a51fc70a15e Author: vlivanov Date: 2013-02-05 08:25 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6a51fc70a15e 8006613: adding reason to made_not_compilable Reviewed-by: kvn, vlivanov Contributed-by: Igor Ignatyev ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 4fcf990aa34a Author: drchase Date: 2013-02-06 11:33 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4fcf990aa34a 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray Summary: check ndimensions before accessing length[i] element Reviewed-by: kvn Contributed-by: volker.simonis at gmail.com ! src/share/vm/opto/parse3.cpp Changeset: d05ff4bf41b3 Author: vlivanov Date: 2013-02-07 12:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d05ff4bf41b3 Merge ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.hpp Changeset: db9981fd3124 Author: jprovino Date: 2013-01-23 13:02 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/db9981fd3124 8005915: Unify SERIALGC and INCLUDE_ALTERNATE_GCS Summary: Rename INCLUDE_ALTERNATE_GCS to INCLUDE_ALL_GCS and replace SERIALGC with INCLUDE_ALL_GCS. Reviewed-by: coleenp, stefank ! make/bsd/makefiles/minimal1.make ! make/excludeSrc.make ! make/linux/makefiles/minimal1.make ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/shared/allocationStats.cpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.cpp ! src/share/vm/gc_implementation/shared/isGCActiveMark.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/generationSpec.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceClassLoaderKlass.cpp ! src/share/vm/oops/instanceClassLoaderKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassPS.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/g1MemoryPool.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/psMemoryPool.hpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/top.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 8391fdd36e1f Author: dlong Date: 2013-01-27 01:07 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8391fdd36e1f Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp Changeset: 3c9bc17b9403 Author: bpittore Date: 2013-02-07 16:05 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3c9bc17b9403 Merge ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: df8462fbe585 Author: vladidan Date: 2013-02-07 20:40 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/df8462fbe585 Merge ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: ec0c4951286c Author: stefank Date: 2013-01-29 10:51 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ec0c4951286c 8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal Summary: When calculating live object regions, make sure that the alignment reserve, at the end of a TLAB, is excluded. Reviewed-by: jmasa, brutisso ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/runtime/vmStructs.cpp Changeset: 4700e77d44c1 Author: johnc Date: 2013-02-01 13:17 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4700e77d44c1 8006894: G1: Number of marking threads missing from PrintFlagsFinal output Summary: Set ConcGCThreads to the calculated number of marking threads. Reviewed-by: jmasa, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: d9058e388631 Author: mikael Date: 2013-02-01 17:21 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d9058e388631 8007257: NPG: metaspace.cpp: Incorrect arguments in calls to err_msg Summary: Fix size checks in assert and corrected some print formats. Also reviewed by vitalyd at gmail.com. Reviewed-by: coleenp, sspitsyn ! src/share/vm/memory/metaspace.cpp Changeset: 256d3f43c177 Author: johnc Date: 2013-01-31 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/256d3f43c177 8005875: G1: Kitchensink fails with ParallelGCThreads=0 Summary: Check that the concurrent marking worker gang exists in ConcurrentMark::print_worker_threads_on(). Changes were also reviewed by Vitaly Davidovich . Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 80518f4ecf32 Author: jmasa Date: 2013-02-04 12:51 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/80518f4ecf32 Merge ! src/share/vm/runtime/vmStructs.cpp Changeset: f2f0cf0f5444 Author: jmasa Date: 2013-02-04 13:26 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f2f0cf0f5444 Merge Changeset: 06fd03af6ce4 Author: johnc Date: 2013-02-04 13:24 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/06fd03af6ce4 8001384: G1: assert(!is_null(v)) failed: narrow oop value can never be zero Summary: Flush any deferred card mark before a Java thread exits. Reviewed-by: brutisso, jmasa ! src/share/vm/runtime/thread.cpp Changeset: 84304a77c4e3 Author: johnc Date: 2013-02-04 19:40 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/84304a77c4e3 Merge Changeset: 95ccff9eee8e Author: jwilhelm Date: 2013-01-28 15:41 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/95ccff9eee8e 6348447: Specifying -XX:OldSize crashes 64-bit VMs Summary: Heap size will be set to allow for OldSize to fit. Also reviewed by vitalyd at gmail.com Reviewed-by: ehelin, jmasa ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: f90b9bceb8e5 Author: johnc Date: 2013-02-05 09:13 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f90b9bceb8e5 8005032: G1: Cleanup serial reference processing closures in concurrent marking Summary: Reuse the parallel reference processing oop closures during serial reference processing. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 50d3b37d5bcd Author: johnc Date: 2013-02-05 22:24 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/50d3b37d5bcd Merge Changeset: 1135141fb97e Author: brutisso Date: 2013-02-08 10:08 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1135141fb97e Merge ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 412d722168bc Author: amurillo Date: 2013-02-08 08:07 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/412d722168bc Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make - test/runtime/7158988/TestFieldMonitor.sh Changeset: cdb46031e718 Author: amurillo Date: 2013-02-08 08:07 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/cdb46031e718 Added tag hs25-b18 for changeset 412d722168bc ! .hgtags From philip.race at oracle.com Wed Feb 13 00:45:10 2013 From: philip.race at oracle.com (Phil Race) Date: Tue, 12 Feb 2013 16:45:10 -0800 Subject: build JDK 7 Windows 7: make jdk fails building sounds In-Reply-To: <1AC3281AD57A34468B9879C754022CAF05F1556F14@exchange.vocera.local> References: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> <1AC3281AD57A34468B9879C754022CAF05F1556C9D@exchange.vocera.local> <511A9AF4.60300@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F14@exchange.vocera.local> Message-ID: <511AE216.70309@oracle.com> I've filed a bug JDK-8008022 to upgrade to June 2010. I'll add your suggestion about Oct 2004 as a workaround but if Microsoft have a rolling removal policy that'll be gone soon too. -phil. On 2/12/2013 4:43 PM, Randy Nielsen wrote: > Building with DirectX 9 publicly available builds from 2006, the closest I can find to 2004, fails. However with access to a DirectX 9 build only available on MSDN with a login I found a DirectX version from October 2004: dxsdk_oct2004.exe. When I installed this I was finally able to successfully build OpenJDK JDK 7. About time! > > Unfortunately I can't redistribute this file, but it is available through MSDN. > > Regards, > > Randy > > -----Original Message----- > From: Phil Race [mailto:philip.race at oracle.com] > Sent: Tuesday, February 12, 2013 11:42 AM > To: Randy Nielsen > Cc: Kelly O'Hair; build-dev at openjdk.java.net > Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds > > I think Microsoft may have recently removed this. > Typing "summer 2004 direct x sdk" into google, the top hit is a link to the download location but it is no longer is a valid link. > Obviously lots of people already have a copy but I'm not sure if they can redistribute it to you. > > We specified that one because versions before and afterward were unstable. > At least that is what our engineer working on the Direct X pipeline for JDK 6u10 told me. If its no longer available we may need to look into testing a much newer version. June 2010 as we use in FX might be a safe bet. > > -phil. > > > On 2/12/2013 11:25 AM, Randy Nielsen wrote: >> Actually I think this failure is because I accidentally installed two different versions of the windows 7 sdk. I've rebuilt my system and am starting the build again. >> >> The OpenJDK README does require a specific version of DirectX 9 SDK - the Summer 2004 version. The *problem* is that the Summer 2004 build is not available anywhere - at least I couldn't find it. I settled for August 2006 build, which was the closest I could find. If you or anyone could point me at a link with the 2004 build I'd be grateful. >> >> For Windows at least the OpenJDK build seems to me to be fraught with difficulties in getting the correct version of tools that work together. Most notable are some Microsoft products (DirectX) and recent versions of Cygwin hanging building Hotspot. The almost impossibility of clean uninstalls of Microsoft products adds to the difficulties here. I'm not sure anything can be done about this, at least for a make system for JDK 7 that is clearly long in the tooth. >> >> Do you think that the JDK8 build system will be sturdier with Windows? >> >> Regards, >> >> Randy >> >> -----Original Message----- >> From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] >> Sent: Tuesday, February 12, 2013 11:11 AM >> To: Randy Nielsen >> Cc: build-dev at openjdk.java.net >> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >> >> It is my understanding that this is why we require the use of a specific DirectX SDK. >> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html# >> dxsdk >> >> -kto >> >> >> On Feb 8, 2013, at 7:07 PM, Randy Nielsen wrote: >> >>> "make jdk" fails building JavaX Sounds library in the include file objidl.h. Output is below. The compiler fails trying to use this: "__RPC__out_xcount_part". The web suggests that the fix is obtained by placing your SDK entries before your VC entries in the PATH and the LIB. I've done this but failure is the same. Does anyone have any suggestions? >>> >>> Randy >>> >>> Building lib:C:/OpenJDK/openjdk/build/windows-amd64/bin/jsoundds.dll >>> "C:/PROGRA~2/MICROS~2.0/Common7/Tools"/../../Vc/bin/amd64/cl -O1 -Zi >>> -nologo -M D /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB >>> -Zc:wchar_t- -FdC:/OpenJ >>> DK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundds/obj64/PLA >>> T >>> FORM_API_W inOS_DirectSound.pdb >>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sou >>> nd/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 -D _CRT_SECURE_ >>> NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE -DNDEBUG -DWIN32 -DIAL -D_LITTLE_END >>> IAN -D_AMD64_ -Damd64 -DWIN32_LEAN_AND_MEAN -I. >>> -IC:/OpenJDK/openjdk/build/windo >>> ws-amd64/tmp/sun/javax.sound/jsoundds/CClassHeaders >>> -I../../../../src/windows/ja vavm/export -I../../../../src/share/javavm/export -I../../../../src/share/native /common -I../../../../src/windows/native/common -I../../../../src/share/native/j >>> avax/sound -I../../../../src/windows/native/javax/sound -DX_PLATFORM=X_WINDOWS >>> -DX_ARCH=X_AMD64 -DUSE_DAUDIO=TRUE >>> -I../../../../src/share/native/com/sun/media >>> /sound -IC:/PROGRA~2/MI4ADD~1/Include -c >>> -FoC:/OpenJDK/openjdk/build/windows-am >>> d64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.obj ../.. >>> /../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_Dire >>> c >>> tSound.cpp >>> >>> PLATFORM_API_WinOS_DirectSound.cpp >>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11280) : error C2061: syntax error : >>> identifier '__RPC__out_xcount_part' >>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : error C2059: syntax error : >>> ')' >>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : fatal error C1903: >>> unable to recover from previous error(s); stopping compilation >>> make[4]: *** >>> [C:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundd >>> s/obj64/PLATFORM_API_WinOS_DirectSound.obj] Error 2 >>> make[4]: Leaving directory >>> `/cygdrive/c/OpenJDK/openjdk/jdk/make/javax/sound/jso From david.katleman at oracle.com Wed Feb 13 00:49:36 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 13 Feb 2013 00:49:36 +0000 Subject: hg: jdk8/build/jaxp: 3 new changesets Message-ID: <20130213004945.BCCFB479FC@hg.openjdk.java.net> Changeset: 02195d0e96b9 Author: katleman Date: 2013-02-07 12:32 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/02195d0e96b9 Added tag jdk8-b76 for changeset 0c08593944d0 ! .hgtags Changeset: f0ad3747b40e Author: emc Date: 2013-02-05 14:56 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/f0ad3747b40e 8007389: Remove uses of _ as identifier in jaxp Reviewed-by: lancea, joehw ! src/javax/xml/validation/SchemaFactoryFinder.java ! src/javax/xml/xpath/XPathFactoryFinder.java Changeset: 573e789c187a Author: lana Date: 2013-02-11 16:12 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/573e789c187a Merge From david.katleman at oracle.com Wed Feb 13 00:49:50 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 13 Feb 2013 00:49:50 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b76 for changeset c4853f3f0e89 Message-ID: <20130213004954.33C14479FD@hg.openjdk.java.net> Changeset: 64dfba1bad16 Author: katleman Date: 2013-02-07 12:33 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/64dfba1bad16 Added tag jdk8-b76 for changeset c4853f3f0e89 ! .hgtags From rnielsen at vocera.com Wed Feb 13 00:51:16 2013 From: rnielsen at vocera.com (Randy Nielsen) Date: Tue, 12 Feb 2013 16:51:16 -0800 Subject: build JDK 7 Windows 7: make jdk fails building sounds In-Reply-To: <511AE216.70309@oracle.com> References: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> <1AC3281AD57A34468B9879C754022CAF05F1556C9D@exchange.vocera.local> <511A9AF4.60300@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F14@exchange.vocera.local> <511AE216.70309@oracle.com> Message-ID: <1AC3281AD57A34468B9879C754022CAF05F1556F20@exchange.vocera.local> MSDN usually keeps old products around a very long time (you can still get Windows 3.1), but the obvious problem for the open source community is that it is not publicly available. Do you have a perspective on how stable-complete the JDK 8 build is or will be, especially for Windows? Randy -----Original Message----- From: Phil Race [mailto:philip.race at oracle.com] Sent: Tuesday, February 12, 2013 4:45 PM To: Randy Nielsen Cc: Kelly O'Hair; build-dev at openjdk.java.net Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds I've filed a bug JDK-8008022 to upgrade to June 2010. I'll add your suggestion about Oct 2004 as a workaround but if Microsoft have a rolling removal policy that'll be gone soon too. -phil. On 2/12/2013 4:43 PM, Randy Nielsen wrote: > Building with DirectX 9 publicly available builds from 2006, the closest I can find to 2004, fails. However with access to a DirectX 9 build only available on MSDN with a login I found a DirectX version from October 2004: dxsdk_oct2004.exe. When I installed this I was finally able to successfully build OpenJDK JDK 7. About time! > > Unfortunately I can't redistribute this file, but it is available through MSDN. > > Regards, > > Randy > > -----Original Message----- > From: Phil Race [mailto:philip.race at oracle.com] > Sent: Tuesday, February 12, 2013 11:42 AM > To: Randy Nielsen > Cc: Kelly O'Hair; build-dev at openjdk.java.net > Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds > > I think Microsoft may have recently removed this. > Typing "summer 2004 direct x sdk" into google, the top hit is a link to the download location but it is no longer is a valid link. > Obviously lots of people already have a copy but I'm not sure if they can redistribute it to you. > > We specified that one because versions before and afterward were unstable. > At least that is what our engineer working on the Direct X pipeline for JDK 6u10 told me. If its no longer available we may need to look into testing a much newer version. June 2010 as we use in FX might be a safe bet. > > -phil. > > > On 2/12/2013 11:25 AM, Randy Nielsen wrote: >> Actually I think this failure is because I accidentally installed two different versions of the windows 7 sdk. I've rebuilt my system and am starting the build again. >> >> The OpenJDK README does require a specific version of DirectX 9 SDK - the Summer 2004 version. The *problem* is that the Summer 2004 build is not available anywhere - at least I couldn't find it. I settled for August 2006 build, which was the closest I could find. If you or anyone could point me at a link with the 2004 build I'd be grateful. >> >> For Windows at least the OpenJDK build seems to me to be fraught with difficulties in getting the correct version of tools that work together. Most notable are some Microsoft products (DirectX) and recent versions of Cygwin hanging building Hotspot. The almost impossibility of clean uninstalls of Microsoft products adds to the difficulties here. I'm not sure anything can be done about this, at least for a make system for JDK 7 that is clearly long in the tooth. >> >> Do you think that the JDK8 build system will be sturdier with Windows? >> >> Regards, >> >> Randy >> >> -----Original Message----- >> From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] >> Sent: Tuesday, February 12, 2013 11:11 AM >> To: Randy Nielsen >> Cc: build-dev at openjdk.java.net >> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >> >> It is my understanding that this is why we require the use of a specific DirectX SDK. >> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html >> # >> dxsdk >> >> -kto >> >> >> On Feb 8, 2013, at 7:07 PM, Randy Nielsen wrote: >> >>> "make jdk" fails building JavaX Sounds library in the include file objidl.h. Output is below. The compiler fails trying to use this: "__RPC__out_xcount_part". The web suggests that the fix is obtained by placing your SDK entries before your VC entries in the PATH and the LIB. I've done this but failure is the same. Does anyone have any suggestions? >>> >>> Randy >>> >>> Building lib:C:/OpenJDK/openjdk/build/windows-amd64/bin/jsoundds.dll >>> "C:/PROGRA~2/MICROS~2.0/Common7/Tools"/../../Vc/bin/amd64/cl -O1 >>> -Zi -nologo -M D /D _STATIC_CPPLIB /D >>> _DISABLE_DEPRECATE_STATIC_CPPLIB >>> -Zc:wchar_t- -FdC:/OpenJ >>> DK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundds/obj64/PL >>> A >>> T >>> FORM_API_W inOS_DirectSound.pdb >>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sou >>> nd/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 -D _CRT_SECURE_ >>> NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE -DNDEBUG -DWIN32 -DIAL -D_LITTLE_END >>> IAN -D_AMD64_ -Damd64 -DWIN32_LEAN_AND_MEAN -I. >>> -IC:/OpenJDK/openjdk/build/windo >>> ws-amd64/tmp/sun/javax.sound/jsoundds/CClassHeaders >>> -I../../../../src/windows/ja vavm/export -I../../../../src/share/javavm/export -I../../../../src/share/native /common -I../../../../src/windows/native/common -I../../../../src/share/native/j >>> avax/sound -I../../../../src/windows/native/javax/sound -DX_PLATFORM=X_WINDOWS >>> -DX_ARCH=X_AMD64 -DUSE_DAUDIO=TRUE >>> -I../../../../src/share/native/com/sun/media >>> /sound -IC:/PROGRA~2/MI4ADD~1/Include -c >>> -FoC:/OpenJDK/openjdk/build/windows-am >>> d64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.obj ../.. >>> /../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_Dir >>> e >>> c >>> tSound.cpp >>> >>> PLATFORM_API_WinOS_DirectSound.cpp >>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11280) : error C2061: syntax error : >>> identifier '__RPC__out_xcount_part' >>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : error C2059: syntax error : >>> ')' >>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : fatal error C1903: >>> unable to recover from previous error(s); stopping compilation >>> make[4]: *** >>> [C:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundd >>> s/obj64/PLATFORM_API_WinOS_DirectSound.obj] Error 2 >>> make[4]: Leaving directory >>> `/cygdrive/c/OpenJDK/openjdk/jdk/make/javax/sound/jso From david.katleman at oracle.com Wed Feb 13 00:50:49 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 13 Feb 2013 00:50:49 +0000 Subject: hg: jdk8/build/jdk: 40 new changesets Message-ID: <20130213005841.232F7479FE@hg.openjdk.java.net> Changeset: 933742f4bb4c Author: katleman Date: 2013-02-07 12:33 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/933742f4bb4c Added tag jdk8-b76 for changeset 3a2630528661 ! .hgtags Changeset: e63e7ee18412 Author: bae Date: 2013-02-01 20:06 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e63e7ee18412 8004801: The image of BufferedImage.TYPE_INT_ARGB is blank. Reviewed-by: prr ! src/share/native/sun/awt/image/awt_parseImage.c ! src/solaris/native/sun/awt/awt_Mlib.c ! src/solaris/native/sun/awt/awt_Mlib.h ! src/windows/native/sun/windows/awt_Mlib.cpp ! src/windows/native/sun/windows/awt_Mlib.h + test/java/awt/image/LookupOp/IntImageReverseTest.java Changeset: 1df2944db538 Author: serb Date: 2013-02-04 19:50 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1df2944db538 8004821: Graphics2D.drawPolygon() fails with IllegalPathStateException Reviewed-by: prr, flar ! src/share/classes/sun/java2d/pipe/PixelToShapeConverter.java + test/sun/java2d/pipe/Test8004821.java Changeset: 8fc3e4015b09 Author: jgodinez Date: 2013-02-04 12:04 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8fc3e4015b09 8005052: [parfait] #416 X11SurfaceData.c UNINITIALISED OR MISSING RETURN VALUE 8005054: [parfait] #417 X11SurfaceData.c UNINITIALISED OR MISSING RETURN VALUE Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c Changeset: fd61fcc1a5a9 Author: leonidr Date: 2013-01-31 18:25 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fd61fcc1a5a9 8007006: [macosx] Closing subwindow loses main window menus Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 452deb976c92 Author: ptbrunet Date: 2013-01-31 18:51 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/452deb976c92 7179482: Component.accessibleContext and JComponent.accessibleContext refactoring Reviewed-by: art, anthony, alexsch ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/javax/swing/JComponent.java Changeset: 0b56a169295f Author: pchelko Date: 2013-02-04 13:54 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0b56a169295f 8005405: [macosx] Drag and Drop: wrong animation when dropped outside any drop target. Summary: Changed the calculation of the drag image offset Reviewed-by: serb, kizune ! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/macosx/native/sun/awt/CDragSource.m Changeset: 171443b1eb3b Author: kshefov Date: 2013-02-04 16:01 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/171443b1eb3b 7077259: [TEST_BUG] [macosx] Test work correctly only when default L&F is Metal Reviewed-by: serb, alexsch ! test/javax/swing/JSlider/4252173/bug4252173.java ! test/javax/swing/JSpinner/6532833/bug6532833.java ! test/javax/swing/plaf/metal/MetalSliderUI/Test6657026.java Changeset: 0e929be3a9da Author: lana Date: 2013-02-05 11:10 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0e929be3a9da Merge Changeset: a343d280bd8c Author: jfranck Date: 2013-01-29 10:32 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a343d280bd8c 8004698: Implement Core Reflection for Type Annotations Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/System.java + src/share/classes/java/lang/reflect/AnnotatedArrayType.java + src/share/classes/java/lang/reflect/AnnotatedParameterizedType.java + src/share/classes/java/lang/reflect/AnnotatedType.java + src/share/classes/java/lang/reflect/AnnotatedTypeVariable.java + src/share/classes/java/lang/reflect/AnnotatedWildcardType.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/ReflectAccess.java ! src/share/classes/java/lang/reflect/TypeVariable.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/LangReflectAccess.java ! src/share/classes/sun/reflect/ReflectionFactory.java + src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java + src/share/classes/sun/reflect/annotation/TypeAnnotation.java + src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/javavm/export/jvm.h ! src/share/native/java/lang/Class.c + test/java/lang/annotation/TypeAnnotationReflection.java + test/java/lang/annotation/TypeParamAnnotation.java Changeset: 5097fe015763 Author: jfranck Date: 2013-01-31 10:10 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5097fe015763 8005712: Simplify support for repeating annotations in j.l.r.AnnotatedElement 8004919: AnnotationSupport uses possibly half-constructed AnnotationType instances Summary: Implements the simplified semantics for repeating annotations and removes the incorrect obtaining of an AnnotationType Reviewed-by: darcy, abuckley ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Parameter.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java ! test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/Container.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainer.java Changeset: 3f766f58c48a Author: dbuck Date: 2013-01-31 10:55 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3f766f58c48a 7042126: (alt-rt) HashMap.clone implementation should be re-examined Summary: Test case for cr7042126. Issue only found in OracleJDK, but test case is valid for OpenJDK as well Reviewed-by: mduigou + test/java/util/HashMap/HashMapCloneLeak.java Changeset: 857d99bef21d Author: sherman Date: 2013-01-31 11:09 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/857d99bef21d 8005394: Base64.Decoder/Encoder.wrap(XStream) don't throw NPE for null args passed Summary: to check null for dec/enc.wrap methods Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java Changeset: 278397f752da Author: darcy Date: 2013-01-31 12:13 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/278397f752da 8005832: Remove java.lang.annotation.{ContainedBy, ContainerFor} annotation types Reviewed-by: mduigou - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java ! src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java Changeset: a5f38e811ab0 Author: darcy Date: 2013-01-31 12:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a5f38e811ab0 8007115: Refactor regression tests for java.lang.reflect.Parameter Reviewed-by: emc ! test/java/lang/reflect/Parameter/WithoutParameters.java Changeset: e5ce312a5b10 Author: sherman Date: 2013-01-31 13:13 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e5ce312a5b10 8007298: Base64.getMimeDecoder().decode() throws IAE for a single non-base64 character 8006526: Base64.Decoder.decode(String) spec contains a copy-paste mistake Summary: to ignore single non-base64 char in mime decoding Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java Changeset: cff8d7768d72 Author: mduigou Date: 2013-01-31 13:27 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/cff8d7768d72 8006709: Add minimal support of MacOSX platform for NetBeans Projects Summary: Adds support for MacOSX platform and architecture detection. Other minor updates (-source/target 1.8) Reviewed-by: ohair + make/netbeans/common/architectures/arch-x86_64.properties + make/netbeans/common/architectures/name-Macosx.properties ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent ! make/netbeans/common/make.xml ! make/netbeans/common/shared.xml Changeset: 771551bc9e02 Author: lana Date: 2013-01-31 10:22 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/771551bc9e02 Merge Changeset: e822b4d50a5b Author: lana Date: 2013-01-31 14:10 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e822b4d50a5b Merge - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java Changeset: a09a37cff333 Author: mchung Date: 2013-01-31 14:29 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a09a37cff333 6355704: (fmt) %f formatting of BigDecimals is incorrect Reviewed-by: darcy Contributed-by: brian.burkhalter at oracle.com ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/BasicBigDecimal.java Changeset: d2495b9984fa Author: weijun Date: 2013-02-01 07:39 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d2495b9984fa 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit Reviewed-by: alanb + test/sun/security/util/Oid/S11N.java - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java Changeset: 17b643956999 Author: chegar Date: 2013-02-01 06:51 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/17b643956999 8006395: Race in async socket close on Linux Reviewed-by: alanb, dsamersoff ! src/solaris/native/java/net/linux_close.c + test/java/net/Socket/asyncClose/Race.java Changeset: ea8f3ca83501 Author: ksrini Date: 2013-02-01 07:25 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ea8f3ca83501 8006536: [launcher] removes trailing slashes on arguments Reviewed-by: ksrini, akhil Contributed-by: jviswana at linux.vnet.ibm.com ! src/windows/bin/cmdtoargs.c ! test/tools/launcher/Arrrghs.java Changeset: 5e47ee4d7196 Author: alanb Date: 2013-02-01 21:01 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5e47ee4d7196 5035569: Formatter should document that %a conversion unsupported for BigDecimal args Reviewed-by: darcy Contributed-by: brian.burkhalter at oracle.com ! src/share/classes/java/util/Formatter.java Changeset: cba578db5f39 Author: darcy Date: 2013-02-01 19:30 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/cba578db5f39 6964528: Double.toHexString(double d) String manipulation with + in an append of StringBuilder Reviewed-by: shade ! src/share/classes/java/lang/Double.java Changeset: c1aaa8451547 Author: ksrini Date: 2013-02-01 22:12 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c1aaa8451547 8003549: (pack200) assertion errors when processing lambda class files with IMethods Summary: add more check for opcode, sketch provided by jrose Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java ! test/ProblemList.txt + test/tools/pack200/InstructionTests.java ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java Changeset: 6c88a12ea834 Author: ksrini Date: 2013-02-01 22:18 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6c88a12ea834 8007428: [launcher] add tools/launcher/FXLauncherTest.java to ProblemList.txt Reviewed-by: mchung ! test/ProblemList.txt Changeset: ee83319029a5 Author: chegar Date: 2013-02-02 17:15 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ee83319029a5 8007322: untangle ftp protocol from general networking URL tests Reviewed-by: alanb ! test/java/net/URL/Constructor.java ! test/java/net/URL/HandlerLoop.java ! test/java/net/URL/Test.java ! test/java/net/URL/URIToURLTest.java - test/java/net/URL/abnormal_http_urls - test/java/net/URL/ftp_urls - test/java/net/URL/jar_urls - test/java/net/URL/normal_http_urls - test/java/net/URL/runconstructor.sh - test/java/net/URL/share_file_urls - test/java/net/URL/win32_file_urls ! test/java/net/URLConnection/RequestProperties.java ! test/java/net/URLConnection/RequestPropertyValues.java + test/sun/net/ftp/EncDec.doc + test/sun/net/ftp/MarkResetTest.java + test/sun/net/ftp/MarkResetTest.sh - test/sun/net/www/EncDec.doc - test/sun/net/www/MarkResetTest.java - test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/HttpClient/ProxyTest.java Changeset: 25831e7009c4 Author: ksrini Date: 2013-02-02 12:08 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/25831e7009c4 8007135: tools/launcher/VersionCheck.java failing with new tool jabswitch Reviewed-by: ksrini, mduigou Contributed-by: ragini.prasad at oracle.com ! test/tools/launcher/VersionCheck.java Changeset: 308d1362b60a Author: dmeetry Date: 2013-02-03 18:20 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/308d1362b60a 6471906: java.lang.NegativeArraySizeException in tenToThe Reviewed-by: darcy Contributed-by: brian.burkhalter at oracle.com ! src/share/classes/java/math/BigDecimal.java Changeset: 962d6612cace Author: dsamersoff Date: 2013-02-03 21:39 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/962d6612cace 8002048: Protocol to discovery of manageable Java processes on a network Summary: Introduce a protocol to discover manageble Java instances across a network subnet, JDP Reviewed-by: sla, dfuchs ! src/share/classes/sun/management/Agent.java + src/share/classes/sun/management/jdp/JdpBroadcaster.java + src/share/classes/sun/management/jdp/JdpController.java + src/share/classes/sun/management/jdp/JdpException.java + src/share/classes/sun/management/jdp/JdpGenericPacket.java + src/share/classes/sun/management/jdp/JdpJmxPacket.java + src/share/classes/sun/management/jdp/JdpPacket.java + src/share/classes/sun/management/jdp/JdpPacketReader.java + src/share/classes/sun/management/jdp/JdpPacketWriter.java + src/share/classes/sun/management/jdp/package-info.java + test/sun/management/jdp/JdpClient.java + test/sun/management/jdp/JdpDoSomething.java + test/sun/management/jdp/JdpTest.sh + test/sun/management/jdp/JdpUnitTest.java Changeset: 5bf1c9e6be60 Author: vinnie Date: 2013-02-04 17:20 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5bf1c9e6be60 8006994: Cleanup PKCS12 tests to ensure streams get closed Reviewed-by: mullan ! test/java/security/KeyStore/PBETest.java ! test/sun/security/pkcs12/StorePasswordTest.java ! test/sun/security/pkcs12/StoreSecretKeyTest.java ! test/sun/security/pkcs12/StoreTrustedCertTest.java Changeset: e202f43a8b8a Author: sherman Date: 2013-02-04 11:58 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e202f43a8b8a 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream 8006315: Base64.Decoder decoding methods are not consistent in treating non-padded data 8006530: Base64.getMimeDecoder().decode() throws exception for non-base64 character after adding = Summary: updated the spec to describe the expected behave explicitly and the implementation to follow Reviewed-by: alanb, chegar, lancea ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java Changeset: e04467fa13af Author: darcy Date: 2013-02-04 17:56 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e04467fa13af 8007113: Upgrade AnnotatedElement.isAnnotionPresent to be a default method Reviewed-by: chegar, jfranck ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Parameter.java ! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java Changeset: fd37f0846653 Author: lana Date: 2013-02-04 22:37 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fd37f0846653 Merge Changeset: 9ffcd758e2be Author: jbachorik Date: 2013-02-05 12:28 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9ffcd758e2be 7170447: Intermittent DeadListenerTest.java failure Summary: Due to asynchronous nature of processing server notifications it may happen that an "unregister" notification ha$ Reviewed-by: sjiang ! test/javax/management/remote/mandatory/notif/DeadListenerTest.java Changeset: 3119f0ebb58d Author: jbachorik Date: 2013-02-05 12:36 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3119f0ebb58d 8005791: Remove java.beans.* imports from com.sun.jmx.mbeanserver.Introspector Reviewed-by: rbackman ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java Changeset: e526277b51be Author: vinnie Date: 2013-02-05 14:25 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e526277b51be 8007483: attributes are ignored when loading keys from a PKCS12 keystore Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! test/sun/security/pkcs12/StorePasswordTest.java Changeset: f26b539bf1d5 Author: lana Date: 2013-02-05 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f26b539bf1d5 Merge - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java - test/java/net/URL/abnormal_http_urls - test/java/net/URL/ftp_urls - test/java/net/URL/jar_urls - test/java/net/URL/normal_http_urls - test/java/net/URL/runconstructor.sh - test/java/net/URL/share_file_urls - test/java/net/URL/win32_file_urls - test/sun/net/www/EncDec.doc - test/sun/net/www/MarkResetTest.java - test/sun/net/www/MarkResetTest.sh - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java Changeset: b2fc8e31cecc Author: lana Date: 2013-02-11 16:14 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b2fc8e31cecc Merge - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java - test/java/net/URL/abnormal_http_urls - test/java/net/URL/ftp_urls - test/java/net/URL/jar_urls - test/java/net/URL/normal_http_urls - test/java/net/URL/runconstructor.sh - test/java/net/URL/share_file_urls - test/java/net/URL/win32_file_urls - test/sun/net/www/EncDec.doc - test/sun/net/www/MarkResetTest.java - test/sun/net/www/MarkResetTest.sh - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java From philip.race at oracle.com Wed Feb 13 01:09:15 2013 From: philip.race at oracle.com (Phil Race) Date: Tue, 12 Feb 2013 17:09:15 -0800 Subject: build JDK 7 Windows 7: make jdk fails building sounds In-Reply-To: <1AC3281AD57A34468B9879C754022CAF05F1556F20@exchange.vocera.local> References: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> <1AC3281AD57A34468B9879C754022CAF05F1556C9D@exchange.vocera.local> <511A9AF4.60300@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F14@exchange.vocera.local> <511AE216.70309@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F20@exchange.vocera.local> Message-ID: <511AE7BB.6030101@oracle.com> I am not sure if you mean will it be "fixing" this. The JDK 8 new build system should not be making any changes to the choice of library or tools being used here or anywhere else without discussion/consent. This is a product area specific change which will be handled on 2d-dev with appropriate product area testing etc. -phil. On 2/12/2013 4:51 PM, Randy Nielsen wrote: > MSDN usually keeps old products around a very long time (you can still get Windows 3.1), but the obvious problem for the open source community is that it is not publicly available. > > Do you have a perspective on how stable-complete the JDK 8 build is or will be, especially for Windows? > > Randy > > -----Original Message----- > From: Phil Race [mailto:philip.race at oracle.com] > Sent: Tuesday, February 12, 2013 4:45 PM > To: Randy Nielsen > Cc: Kelly O'Hair; build-dev at openjdk.java.net > Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds > > I've filed a bug JDK-8008022 to upgrade to June 2010. > I'll add your suggestion about Oct 2004 as a workaround but if Microsoft have a rolling removal policy that'll be gone soon too. > > -phil. > > On 2/12/2013 4:43 PM, Randy Nielsen wrote: >> Building with DirectX 9 publicly available builds from 2006, the closest I can find to 2004, fails. However with access to a DirectX 9 build only available on MSDN with a login I found a DirectX version from October 2004: dxsdk_oct2004.exe. When I installed this I was finally able to successfully build OpenJDK JDK 7. About time! >> >> Unfortunately I can't redistribute this file, but it is available through MSDN. >> >> Regards, >> >> Randy >> >> -----Original Message----- >> From: Phil Race [mailto:philip.race at oracle.com] >> Sent: Tuesday, February 12, 2013 11:42 AM >> To: Randy Nielsen >> Cc: Kelly O'Hair; build-dev at openjdk.java.net >> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >> >> I think Microsoft may have recently removed this. >> Typing "summer 2004 direct x sdk" into google, the top hit is a link to the download location but it is no longer is a valid link. >> Obviously lots of people already have a copy but I'm not sure if they can redistribute it to you. >> >> We specified that one because versions before and afterward were unstable. >> At least that is what our engineer working on the Direct X pipeline for JDK 6u10 told me. If its no longer available we may need to look into testing a much newer version. June 2010 as we use in FX might be a safe bet. >> >> -phil. >> >> >> On 2/12/2013 11:25 AM, Randy Nielsen wrote: >>> Actually I think this failure is because I accidentally installed two different versions of the windows 7 sdk. I've rebuilt my system and am starting the build again. >>> >>> The OpenJDK README does require a specific version of DirectX 9 SDK - the Summer 2004 version. The *problem* is that the Summer 2004 build is not available anywhere - at least I couldn't find it. I settled for August 2006 build, which was the closest I could find. If you or anyone could point me at a link with the 2004 build I'd be grateful. >>> >>> For Windows at least the OpenJDK build seems to me to be fraught with difficulties in getting the correct version of tools that work together. Most notable are some Microsoft products (DirectX) and recent versions of Cygwin hanging building Hotspot. The almost impossibility of clean uninstalls of Microsoft products adds to the difficulties here. I'm not sure anything can be done about this, at least for a make system for JDK 7 that is clearly long in the tooth. >>> >>> Do you think that the JDK8 build system will be sturdier with Windows? >>> >>> Regards, >>> >>> Randy >>> >>> -----Original Message----- >>> From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] >>> Sent: Tuesday, February 12, 2013 11:11 AM >>> To: Randy Nielsen >>> Cc: build-dev at openjdk.java.net >>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>> >>> It is my understanding that this is why we require the use of a specific DirectX SDK. >>> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html >>> # >>> dxsdk >>> >>> -kto >>> >>> >>> On Feb 8, 2013, at 7:07 PM, Randy Nielsen wrote: >>> >>>> "make jdk" fails building JavaX Sounds library in the include file objidl.h. Output is below. The compiler fails trying to use this: "__RPC__out_xcount_part". The web suggests that the fix is obtained by placing your SDK entries before your VC entries in the PATH and the LIB. I've done this but failure is the same. Does anyone have any suggestions? >>>> >>>> Randy >>>> >>>> Building lib:C:/OpenJDK/openjdk/build/windows-amd64/bin/jsoundds.dll >>>> "C:/PROGRA~2/MICROS~2.0/Common7/Tools"/../../Vc/bin/amd64/cl -O1 >>>> -Zi -nologo -M D /D _STATIC_CPPLIB /D >>>> _DISABLE_DEPRECATE_STATIC_CPPLIB >>>> -Zc:wchar_t- -FdC:/OpenJ >>>> DK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundds/obj64/PL >>>> A >>>> T >>>> FORM_API_W inOS_DirectSound.pdb >>>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sou >>>> nd/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 -D _CRT_SECURE_ >>>> NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE -DNDEBUG -DWIN32 -DIAL -D_LITTLE_END >>>> IAN -D_AMD64_ -Damd64 -DWIN32_LEAN_AND_MEAN -I. >>>> -IC:/OpenJDK/openjdk/build/windo >>>> ws-amd64/tmp/sun/javax.sound/jsoundds/CClassHeaders >>>> -I../../../../src/windows/ja vavm/export -I../../../../src/share/javavm/export -I../../../../src/share/native /common -I../../../../src/windows/native/common -I../../../../src/share/native/j >>>> avax/sound -I../../../../src/windows/native/javax/sound -DX_PLATFORM=X_WINDOWS >>>> -DX_ARCH=X_AMD64 -DUSE_DAUDIO=TRUE >>>> -I../../../../src/share/native/com/sun/media >>>> /sound -IC:/PROGRA~2/MI4ADD~1/Include -c >>>> -FoC:/OpenJDK/openjdk/build/windows-am >>>> d64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.obj ../.. >>>> /../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_Dir >>>> e >>>> c >>>> tSound.cpp >>>> >>>> PLATFORM_API_WinOS_DirectSound.cpp >>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11280) : error C2061: syntax error : >>>> identifier '__RPC__out_xcount_part' >>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : error C2059: syntax error : >>>> ')' >>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : fatal error C1903: >>>> unable to recover from previous error(s); stopping compilation >>>> make[4]: *** >>>> [C:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundd >>>> s/obj64/PLATFORM_API_WinOS_DirectSound.obj] Error 2 >>>> make[4]: Leaving directory >>>> `/cygdrive/c/OpenJDK/openjdk/jdk/make/javax/sound/jso From philip.race at oracle.com Wed Feb 13 01:10:41 2013 From: philip.race at oracle.com (Phil Race) Date: Tue, 12 Feb 2013 17:10:41 -0800 Subject: build JDK 7 Windows 7: make jdk fails building sounds In-Reply-To: <511AE7BB.6030101@oracle.com> References: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> <1AC3281AD57A34468B9879C754022CAF05F1556C9D@exchange.vocera.local> <511A9AF4.60300@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F14@exchange.vocera.local> <511AE216.70309@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F20@exchange.vocera.local> <511AE7BB.6030101@oracle.com> Message-ID: <511AE811.4040401@oracle.com> 2d-dev *and* sound-dev I should say .. -phil. On 2/12/2013 5:09 PM, Phil Race wrote: > I am not sure if you mean will it be "fixing" this. > The JDK 8 new build system should not be making any changes to the choice > of library or tools being used here or anywhere else without > discussion/consent. > This is a product area specific change which will be handled on 2d-dev > with > appropriate product area testing etc. > > -phil. > > On 2/12/2013 4:51 PM, Randy Nielsen wrote: >> MSDN usually keeps old products around a very long time (you can >> still get Windows 3.1), but the obvious problem for the open source >> community is that it is not publicly available. >> >> Do you have a perspective on how stable-complete the JDK 8 build is >> or will be, especially for Windows? >> >> Randy >> >> -----Original Message----- >> From: Phil Race [mailto:philip.race at oracle.com] >> Sent: Tuesday, February 12, 2013 4:45 PM >> To: Randy Nielsen >> Cc: Kelly O'Hair; build-dev at openjdk.java.net >> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >> >> I've filed a bug JDK-8008022 to upgrade to June 2010. >> I'll add your suggestion about Oct 2004 as a workaround but if >> Microsoft have a rolling removal policy that'll be gone soon too. >> >> -phil. >> >> On 2/12/2013 4:43 PM, Randy Nielsen wrote: >>> Building with DirectX 9 publicly available builds from 2006, the >>> closest I can find to 2004, fails. However with access to a DirectX >>> 9 build only available on MSDN with a login I found a DirectX >>> version from October 2004: dxsdk_oct2004.exe. When I installed this >>> I was finally able to successfully build OpenJDK JDK 7. About time! >>> >>> Unfortunately I can't redistribute this file, but it is available >>> through MSDN. >>> >>> Regards, >>> >>> Randy >>> >>> -----Original Message----- >>> From: Phil Race [mailto:philip.race at oracle.com] >>> Sent: Tuesday, February 12, 2013 11:42 AM >>> To: Randy Nielsen >>> Cc: Kelly O'Hair; build-dev at openjdk.java.net >>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>> >>> I think Microsoft may have recently removed this. >>> Typing "summer 2004 direct x sdk" into google, the top hit is a link >>> to the download location but it is no longer is a valid link. >>> Obviously lots of people already have a copy but I'm not sure if >>> they can redistribute it to you. >>> >>> We specified that one because versions before and afterward were >>> unstable. >>> At least that is what our engineer working on the Direct X pipeline >>> for JDK 6u10 told me. If its no longer available we may need to look >>> into testing a much newer version. June 2010 as we use in FX might >>> be a safe bet. >>> >>> -phil. >>> >>> >>> On 2/12/2013 11:25 AM, Randy Nielsen wrote: >>>> Actually I think this failure is because I accidentally installed >>>> two different versions of the windows 7 sdk. I've rebuilt my >>>> system and am starting the build again. >>>> >>>> The OpenJDK README does require a specific version of DirectX 9 SDK >>>> - the Summer 2004 version. The *problem* is that the Summer 2004 >>>> build is not available anywhere - at least I couldn't find it. I >>>> settled for August 2006 build, which was the closest I could find. >>>> If you or anyone could point me at a link with the 2004 build I'd >>>> be grateful. >>>> >>>> For Windows at least the OpenJDK build seems to me to be fraught >>>> with difficulties in getting the correct version of tools that work >>>> together. Most notable are some Microsoft products (DirectX) and >>>> recent versions of Cygwin hanging building Hotspot. The almost >>>> impossibility of clean uninstalls of Microsoft products adds to the >>>> difficulties here. I'm not sure anything can be done about this, >>>> at least for a make system for JDK 7 that is clearly long in the >>>> tooth. >>>> >>>> Do you think that the JDK8 build system will be sturdier with Windows? >>>> >>>> Regards, >>>> >>>> Randy >>>> >>>> -----Original Message----- >>>> From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] >>>> Sent: Tuesday, February 12, 2013 11:11 AM >>>> To: Randy Nielsen >>>> Cc: build-dev at openjdk.java.net >>>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>>> >>>> It is my understanding that this is why we require the use of a >>>> specific DirectX SDK. >>>> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html >>>> # >>>> dxsdk >>>> >>>> -kto >>>> >>>> >>>> On Feb 8, 2013, at 7:07 PM, Randy Nielsen wrote: >>>> >>>>> "make jdk" fails building JavaX Sounds library in the include file >>>>> objidl.h. Output is below. The compiler fails trying to use >>>>> this: "__RPC__out_xcount_part". The web suggests that the fix is >>>>> obtained by placing your SDK entries before your VC entries in the >>>>> PATH and the LIB. I've done this but failure is the same. Does >>>>> anyone have any suggestions? >>>>> >>>>> Randy >>>>> >>>>> Building lib:C:/OpenJDK/openjdk/build/windows-amd64/bin/jsoundds.dll >>>>> "C:/PROGRA~2/MICROS~2.0/Common7/Tools"/../../Vc/bin/amd64/cl -O1 >>>>> -Zi -nologo -M D /D _STATIC_CPPLIB /D >>>>> _DISABLE_DEPRECATE_STATIC_CPPLIB >>>>> -Zc:wchar_t- -FdC:/OpenJ >>>>> DK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundds/obj64/PL >>>>> A >>>>> T >>>>> FORM_API_W inOS_DirectSound.pdb >>>>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sou >>>>> nd/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 >>>>> -D _CRT_SECURE_ >>>>> NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE -DNDEBUG -DWIN32 -DIAL >>>>> -D_LITTLE_END >>>>> IAN -D_AMD64_ -Damd64 -DWIN32_LEAN_AND_MEAN -I. >>>>> -IC:/OpenJDK/openjdk/build/windo >>>>> ws-amd64/tmp/sun/javax.sound/jsoundds/CClassHeaders >>>>> -I../../../../src/windows/ja vavm/export >>>>> -I../../../../src/share/javavm/export >>>>> -I../../../../src/share/native /common >>>>> -I../../../../src/windows/native/common >>>>> -I../../../../src/share/native/j >>>>> avax/sound -I../../../../src/windows/native/javax/sound >>>>> -DX_PLATFORM=X_WINDOWS >>>>> -DX_ARCH=X_AMD64 -DUSE_DAUDIO=TRUE >>>>> -I../../../../src/share/native/com/sun/media >>>>> /sound -IC:/PROGRA~2/MI4ADD~1/Include -c >>>>> -FoC:/OpenJDK/openjdk/build/windows-am >>>>> d64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.obj >>>>> ../.. >>>>> /../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_Dir >>>>> e >>>>> c >>>>> tSound.cpp >>>>> >>>>> PLATFORM_API_WinOS_DirectSound.cpp >>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11280) : error C2061: >>>>> syntax error : >>>>> identifier '__RPC__out_xcount_part' >>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : error C2059: >>>>> syntax error : >>>>> ')' >>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : fatal error >>>>> C1903: >>>>> unable to recover from previous error(s); stopping compilation >>>>> make[4]: *** >>>>> [C:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundd >>>>> s/obj64/PLATFORM_API_WinOS_DirectSound.obj] Error 2 >>>>> make[4]: Leaving directory >>>>> `/cygdrive/c/OpenJDK/openjdk/jdk/make/javax/sound/jso > From david.katleman at oracle.com Wed Feb 13 01:00:11 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 13 Feb 2013 01:00:11 +0000 Subject: hg: jdk8/build/langtools: 21 new changesets Message-ID: <20130213010108.DB98F479FF@hg.openjdk.java.net> Changeset: 6fde20398015 Author: katleman Date: 2013-02-07 12:33 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/6fde20398015 Added tag jdk8-b76 for changeset e81839b32337 ! .hgtags Changeset: cbcd9b484759 Author: vromero Date: 2013-01-27 19:38 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/cbcd9b484759 8006944: javac, combo tests should print out the number of threads used Reviewed-by: mcimadamore ! test/tools/javac/lib/JavacTestingAbstractThreadedTest.java Changeset: 950d8195a5a4 Author: jjg Date: 2013-01-30 09:40 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/950d8195a5a4 8007096: DocLint parsing problems with some comments Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java + test/tools/doclint/EndWithIdentifierTest.java + test/tools/doclint/EndWithIdentifierTest.out + test/tools/doclint/UnfinishedInlineTagTest.java + test/tools/doclint/UnfinishedInlineTagTest.out Changeset: c924291865e5 Author: jjg Date: 2013-01-30 09:47 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/c924291865e5 8007034: debug printer for javac internals Reviewed-by: mcimadamore + test/tools/javac/lib/DPrinter.java Changeset: 8e4c22acebeb Author: darcy Date: 2013-01-31 12:16 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/8e4c22acebeb 8007313: Remove use of {ContainerFor/ContainedBy} from langtools Reviewed-by: jjg ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java ! test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java Changeset: b7cb3d7ade25 Author: lana Date: 2013-01-31 10:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/b7cb3d7ade25 Merge Changeset: 7b269e916e06 Author: lana Date: 2013-01-31 14:10 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/7b269e916e06 Merge Changeset: bec996065c45 Author: darcy Date: 2013-01-31 18:58 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/bec996065c45 8007351: Malformed copyright statements in typeAnnotations test directory Reviewed-by: jjg ! test/tools/javac/annotations/typeAnnotations/TargetTypes.java ! test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java ! test/tools/javac/annotations/typeAnnotations/api/AnnotatedArrayOrder.java ! test/tools/javac/annotations/typeAnnotations/api/ArrayCreationTree.java ! test/tools/javac/annotations/typeAnnotations/api/ArrayPositionConsistency.java ! test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java ! test/tools/javac/annotations/typeAnnotations/classfile/NewTypeArguments.java ! test/tools/javac/annotations/typeAnnotations/classfile/NoTargetAnnotations.java ! test/tools/javac/annotations/typeAnnotations/classfile/TypeCasts.java ! test/tools/javac/annotations/typeAnnotations/classfile/Wildcards.java ! test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java ! test/tools/javac/annotations/typeAnnotations/newlocations/Varargs.java ! test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/Anno.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/MyClass.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/package-info.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassExtends.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassTypeParam.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ExceptionParameters.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/FromSpecification.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReceivers.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReturns.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodThrows.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodTypeParam.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/NestedTypes.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/NewObjects.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ReferenceInfoUtil.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/RepeatingTypeAnnotations.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeTests.java Changeset: 3ab64e4293a1 Author: jjg Date: 2013-01-31 19:19 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/3ab64e4293a1 8007329: minor issues in impl class hierarchry for DCTree.* classes Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/tree/DCTree.java Changeset: 3d97a9a7a82b Author: jjg Date: 2013-01-31 19:31 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/3d97a9a7a82b 8004353: Generated html is wrong for overview.html; content has incorrect css footer class Reviewed-by: jjg Contributed-by: roger.riggs at oracle.com ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java Changeset: 8590c20af3ce Author: jjg Date: 2013-02-01 08:33 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/8590c20af3ce 8007306: DPrinter: improve display of impl-class, internal tag/kind, and external tag/kind Reviewed-by: mcimadamore ! test/tools/javac/lib/DPrinter.java Changeset: 6df931ce1a81 Author: jjg Date: 2013-02-01 08:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/6df931ce1a81 8007305: DPrinter: provide better usage message Reviewed-by: mcimadamore ! test/tools/javac/lib/DPrinter.java Changeset: 0b1c88705568 Author: jjg Date: 2013-02-01 12:01 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/0b1c88705568 8007344: javac may not make tree end positions and/or doc comments available to processors and listeners Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/tools/javac/api/8007344/Test.java Changeset: 55cca2f38ee6 Author: darcy Date: 2013-02-01 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/55cca2f38ee6 8001614: Include annotation type to documented supported-ness Reviewed-by: alanb, jjg, tbell ! make/Makefile-classic ! make/build.properties + src/share/classes/jdk/Supported.java Changeset: 4cc73ec94686 Author: vromero Date: 2013-02-02 21:04 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/4cc73ec94686 8005075: Pool.Method, and Pool.Variable redundant Symbol field should be removed Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java Changeset: a51a8dac0a2f Author: vromero Date: 2013-02-03 02:31 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/a51a8dac0a2f 7199823: javac generates inner class that can't be verified Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/7199823/InnerClassCannotBeVerified.java Changeset: 1690928dc560 Author: jjg Date: 2013-02-04 15:30 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/1690928dc560 8007490: NPE from DocumentationTool.run Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/api/JavadocTool.java ! test/tools/javadoc/api/basic/RunTest.java Changeset: 62d91c13dce2 Author: jjg Date: 2013-02-04 18:14 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/62d91c13dce2 8007492: DocumentationTool cannot locate standard doclet when invoked from JRE Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/api/JavadocTool.java Changeset: 10619513f51a Author: lana Date: 2013-02-04 22:38 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/10619513f51a Merge Changeset: 2480aec9a3f1 Author: jjh Date: 2013-02-05 18:55 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/2480aec9a3f1 8007504: Remove @ignore from tests that no longer need it Reviewed-by: mcimadamore ! test/tools/javac/api/T6306137.java ! test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java ! test/tools/javac/lambda/LambdaCapture06.java ! test/tools/javac/lambda/LambdaExpr15.java Changeset: 89c664151689 Author: lana Date: 2013-02-11 16:15 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/89c664151689 Merge From david.holmes at oracle.com Wed Feb 13 02:02:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Feb 2013 12:02:55 +1000 Subject: RFR (S): 8007639: Workaround for ccache in vm.make is incorrect In-Reply-To: <51199C9C.9030909@oracle.com> References: <5115442C.5030309@oracle.com> <51199C9C.9030909@oracle.com> Message-ID: <511AF44F.70401@oracle.com> Oops! Hit reply instead of reply-all. Adding back the lists. On 12/02/2013 11:36 AM, David Holmes wrote: > Hi Mikael, > > So after our side-bar discussions on other ways to tackle this, the only > query I have now is why the original change adjusted CXXFLAGS and this > change adjusts CFLAGS instead? > > Thanks, > David > > On 9/02/2013 4:30 AM, Mikael Vidstedt wrote: >> >> Please review the following change: >> >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.00/webrev >> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007639 >> >> This change corrects the workaround that was introduced in vm.make for >> enabling ccache for HotSpot builds. The change introduces a file >> specific makefile variable (CFLAGS/) which is used to only set >> the JRE_RELEASE_VERSION define when compiling vm_version.o. >> >> Verified manually by observing command lines with/without fix, also >> passes JPRT. >> >> >> Some additional background below, more information is available in the >> bug report: >> >> To enable the use of ccache 7132779 [1] introduced some new makefile >> logic in vm.make to only pass the JRE_RELEASE_VERSION define when >> compiling the vm_version.cpp file. The underlying reason for that is >> that the JRE_RELEASE_VERSION can in some cases contain a time stamp and >> since ccache checks that the defines match before reusing the cache >> version of the object file that would mean that if the time stamp >> changed all files would have to be recompiled. With the fix only >> vm_version.cpp needs to be recompiled. >> >> This almost works, but the logic introduced in the makefile is actually >> incorrect. Today it looks like this: >> >> >> # This is VERY important! The version define must only be supplied to >> vm_version.o >> # If not, ccache will not re-use the cache at all, since the version >> string might contain >> # a time and date. >> vm_version.o: CXXFLAGS += ${JRE_VERSION} >> >> However, the above syntax does not only add the ${JRE_VERSION} to the >> CXXFLAGS of vm_version.o as originally intended - it also /in some >> cases/ adds it to the CXXFLAGS for any and all prerequisites of >> vm_version.o. And vm_version.o depends on all other object files, which >> means in theory this actually passes in that potentially time stamped >> version string define to all object files anyway. For various reasons in >> reality it only passes it to files that are lexicographically after >> vm_version.o - see bug report for more background on why - but there's >> still a handful of files that will be recompiled unnecessarily. >> >> Cheers, >> Mikael >> >> [1] http://bugs.sun.com/view_bug.do?bug_id=7132779 >> From mikael.vidstedt at oracle.com Wed Feb 13 02:32:37 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 12 Feb 2013 18:32:37 -0800 Subject: RFR (S): 8007639: Workaround for ccache in vm.make is incorrect In-Reply-To: <511AF44F.70401@oracle.com> References: <5115442C.5030309@oracle.com> <51199C9C.9030909@oracle.com> <511AF44F.70401@oracle.com> Message-ID: <511AFB45.6010109@oracle.com> Good catch! There is no fundamental reason for switching to CFLAGS, and since the other defines are added to CXXFLAGS so should this. Updated webrev here: http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.01/webrev/ Cheers, Mikael On 2013-02-12 18:02, David Holmes wrote: > Oops! Hit reply instead of reply-all. Adding back the lists. > > On 12/02/2013 11:36 AM, David Holmes wrote: >> Hi Mikael, >> >> So after our side-bar discussions on other ways to tackle this, the only >> query I have now is why the original change adjusted CXXFLAGS and this >> change adjusts CFLAGS instead? >> >> Thanks, >> David >> >> On 9/02/2013 4:30 AM, Mikael Vidstedt wrote: >>> >>> Please review the following change: >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.00/webrev >>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007639 >>> >>> This change corrects the workaround that was introduced in vm.make for >>> enabling ccache for HotSpot builds. The change introduces a file >>> specific makefile variable (CFLAGS/) which is used to only set >>> the JRE_RELEASE_VERSION define when compiling vm_version.o. >>> >>> Verified manually by observing command lines with/without fix, also >>> passes JPRT. >>> >>> >>> Some additional background below, more information is available in the >>> bug report: >>> >>> To enable the use of ccache 7132779 [1] introduced some new makefile >>> logic in vm.make to only pass the JRE_RELEASE_VERSION define when >>> compiling the vm_version.cpp file. The underlying reason for that is >>> that the JRE_RELEASE_VERSION can in some cases contain a time stamp and >>> since ccache checks that the defines match before reusing the cache >>> version of the object file that would mean that if the time stamp >>> changed all files would have to be recompiled. With the fix only >>> vm_version.cpp needs to be recompiled. >>> >>> This almost works, but the logic introduced in the makefile is actually >>> incorrect. Today it looks like this: >>> >>> >>> # This is VERY important! The version define must only be supplied to >>> vm_version.o >>> # If not, ccache will not re-use the cache at all, since the version >>> string might contain >>> # a time and date. >>> vm_version.o: CXXFLAGS += ${JRE_VERSION} >>> >>> However, the above syntax does not only add the ${JRE_VERSION} to the >>> CXXFLAGS of vm_version.o as originally intended - it also /in some >>> cases/ adds it to the CXXFLAGS for any and all prerequisites of >>> vm_version.o. And vm_version.o depends on all other object files, which >>> means in theory this actually passes in that potentially time stamped >>> version string define to all object files anyway. For various >>> reasons in >>> reality it only passes it to files that are lexicographically after >>> vm_version.o - see bug report for more background on why - but there's >>> still a handful of files that will be recompiled unnecessarily. >>> >>> Cheers, >>> Mikael >>> >>> [1] http://bugs.sun.com/view_bug.do?bug_id=7132779 >>> From david.holmes at oracle.com Wed Feb 13 02:35:11 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Feb 2013 12:35:11 +1000 Subject: RFR (S): 8007639: Workaround for ccache in vm.make is incorrect In-Reply-To: <511AFB45.6010109@oracle.com> References: <5115442C.5030309@oracle.com> <51199C9C.9030909@oracle.com> <511AF44F.70401@oracle.com> <511AFB45.6010109@oracle.com> Message-ID: <511AFBDF.7090705@oracle.com> Looks okay to me. David On 13/02/2013 12:32 PM, Mikael Vidstedt wrote: > > Good catch! There is no fundamental reason for switching to CFLAGS, and > since the other defines are added to CXXFLAGS so should this. Updated > webrev here: > > http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.01/webrev/ > > Cheers, > Mikael > > On 2013-02-12 18:02, David Holmes wrote: >> Oops! Hit reply instead of reply-all. Adding back the lists. >> >> On 12/02/2013 11:36 AM, David Holmes wrote: >>> Hi Mikael, >>> >>> So after our side-bar discussions on other ways to tackle this, the only >>> query I have now is why the original change adjusted CXXFLAGS and this >>> change adjusts CFLAGS instead? >>> >>> Thanks, >>> David >>> >>> On 9/02/2013 4:30 AM, Mikael Vidstedt wrote: >>>> >>>> Please review the following change: >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.00/webrev >>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007639 >>>> >>>> This change corrects the workaround that was introduced in vm.make for >>>> enabling ccache for HotSpot builds. The change introduces a file >>>> specific makefile variable (CFLAGS/) which is used to only set >>>> the JRE_RELEASE_VERSION define when compiling vm_version.o. >>>> >>>> Verified manually by observing command lines with/without fix, also >>>> passes JPRT. >>>> >>>> >>>> Some additional background below, more information is available in the >>>> bug report: >>>> >>>> To enable the use of ccache 7132779 [1] introduced some new makefile >>>> logic in vm.make to only pass the JRE_RELEASE_VERSION define when >>>> compiling the vm_version.cpp file. The underlying reason for that is >>>> that the JRE_RELEASE_VERSION can in some cases contain a time stamp and >>>> since ccache checks that the defines match before reusing the cache >>>> version of the object file that would mean that if the time stamp >>>> changed all files would have to be recompiled. With the fix only >>>> vm_version.cpp needs to be recompiled. >>>> >>>> This almost works, but the logic introduced in the makefile is actually >>>> incorrect. Today it looks like this: >>>> >>>> >>>> # This is VERY important! The version define must only be supplied to >>>> vm_version.o >>>> # If not, ccache will not re-use the cache at all, since the version >>>> string might contain >>>> # a time and date. >>>> vm_version.o: CXXFLAGS += ${JRE_VERSION} >>>> >>>> However, the above syntax does not only add the ${JRE_VERSION} to the >>>> CXXFLAGS of vm_version.o as originally intended - it also /in some >>>> cases/ adds it to the CXXFLAGS for any and all prerequisites of >>>> vm_version.o. And vm_version.o depends on all other object files, which >>>> means in theory this actually passes in that potentially time stamped >>>> version string define to all object files anyway. For various >>>> reasons in >>>> reality it only passes it to files that are lexicographically after >>>> vm_version.o - see bug report for more background on why - but there's >>>> still a handful of files that will be recompiled unnecessarily. >>>> >>>> Cheers, >>>> Mikael >>>> >>>> [1] http://bugs.sun.com/view_bug.do?bug_id=7132779 >>>> > From alexandr.scherbatiy at oracle.com Wed Feb 13 11:38:56 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 13 Feb 2013 15:38:56 +0400 Subject: OpenJDK rebuilding on windows takes a long time In-Reply-To: <5118DE08.4080709@oracle.com> References: <5114ED06.1040802@oracle.com> <51150FB3.7@oracle.com> <5118D476.6030203@oracle.com> <5118DE08.4080709@oracle.com> Message-ID: <511B7B50.3070402@oracle.com> On 2/11/2013 4:03 PM, Erik Joelsson wrote: > The long term solution to this is sjavac. I do not know if it has made > it into that forest yet. You can try by adding --enable-sjavac to > configure and do a clean build. If the build works, you have it, and > incremental builds will be much faster. I tried to use the --enable-sjavac option and JDK 7 and 8 as a boot JDK. --with-boot-jdk=/cygdrive/c/Sun/Tools/JDK/jdk7/7u14/b10/jdk1.7.0_14/fastdebug --with-target-bits=32 --enable-sjavac gives compilation error --with-boot-jdk=/cygdrive/c/Sun/Tools/JDK/jdk8/b75/jdk1.8.0/fastdebug --with-target-bits=32 --enable-sjavac gives "OutOfMemoryError: Java heap space" error. The log files are attached. Thanks, Alexandr. > > /Erik > > On 2013-02-11 12:22, Alexander Scherbatiy wrote: >> On 2/8/2013 6:46 PM, Erik Joelsson wrote: >>> Ccache is not supported on windows since it doesn't work with visual >>> studio AFAIK. >>> >>> What kind of change did you do? Was it in native code or java and in >>> which repository? >> I use the http://hg.openjdk.java.net/jdk8/awt repository, edit java >> code and build the jdk. >> To reproduce the issue: >> - open the javax.swing.JFrame class and add a comment line: >> // a comment >> - build jdk >> >> ----- Build times ------- >> Start 2013-02-11 15:09:55 >> End 2013-02-11 15:17:08 >> 00:00:03 corba >> 00:00:02 hotspot >> 00:00:01 jaxp >> 00:00:03 jaxws >> 00:06:54 jdk >> 00:00:02 langtools >> 00:07:13 TOTAL >> ------------------------- >> >> My environment: >> OS: Windows 7 Professional, x64 >> Processor - Intel Core i7 >> Memory - 8 GB >> >> The log file is attached. >> >> Thanks, >> Alexandr. >>> >>> /Erik >>> >> -------------- next part -------------- make[2]: warning: -jN forced in submake: disabling jobserver mode. INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 warning: [options] bootstrap class path not set in conjunction with -source 1.6 Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 1 warning bit length overflow code 3 bits 7->6 code 5 bits 5->6 bit length overflow code 4 bits 6->7 bit length overflow code 6 bits 6->7 bit length overflow code 17 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 17 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 17 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 6 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 17 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 3 bits 7->6 code 4 bits 5->6 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 18 bits 7->6 code 3 bits 5->6 bit length overflow code 5 bits 6->7 bit length overflow code 5 bits 7->6 code 3 bits 5->6 bit length overflow code 4 bits 6->7 bit length overflow code 0 bits 5->6 bit length overflow code 4 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 2 bits 6->7 bit length overflow code 2 bits 6->7 bit length overflow code 6 bits 6->7 bit length overflow code 2 bits 6->7 ************************************************************** ***** WARNING: ASSERT is undefined, assertions disabled. ***** ************************************************************** warning: [options] bootstrap class path not set in conjunction with -source 1.6 1 warning warning: [options] bootstrap class path not set in conjunction with -source 1.6 1 warning cl : Command line warning D9035 : option 'GZ' has been deprecated and will be removed in a future release cl : Command line warning D9036 : use 'RTC1' instead of 'GZ' cl : Command line warning D9035 : option 'o' has been deprecated and will be removed in a future release cl : Command line warning D9002 : ignoring unknown option '-YX' Microsoft (R) Program Maintenance Utility Version 10.00.30319.01 Copyright (C) Microsoft Corporation. All rights reserved. warning: [options] bootstrap class path not set in conjunction with -source 1.6 1 warning INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 c:\Sun\OpenJDK\utils\config\awt\jaxp\src\javax\xml\validation\SchemaFactoryFinder.java:71: warning: '_' used as an identifier } catch (Exception _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxp\src\javax\xml\validation\SchemaFactoryFinder.java:116: warning: '_' used as an identifier } catch( Throwable _ ) { ^ (use of '_' as an identifier might not be supported in future releases) 2 warnings C:\Sun\OpenJDK\utils\config\awt\jaxp\src\javax\xml\validation\SchemaFactoryFinder.java:71: warning: '_' used as an identifier } catch (Exception _) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxp\src\javax\xml\validation\SchemaFactoryFinder.java:116: warning: '_' used as an identifier } catch( Throwable _ ) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxp\src\javax\xml\xpath\XPathFactoryFinder.java:59: warning: '_' used as an identifier } catch (Exception _) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxp\src\javax\xml\xpath\XPathFactoryFinder.java:114: warning: '_' used as an identifier } catch( Throwable _ ) { ^ (use of '_' as an identifier might not be supported in future releases) 4 warnings C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\tools\internal\xjc\Driver.java:225: warning: '_' used as an identifier } catch (WeAreDone _) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\tools\internal\xjc\ModelLoader.java:356: warning: '_' used as an identifier } catch( SpeculationFailure _ ) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\tools\internal\xjc\api\impl\s2j\SchemaCompilerImpl.java:172: warning: '_' used as an identifier } catch( MalformedURLException _ ) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\ws\util\JAXWSUtils.java:128: warning: '_' used as an identifier } catch( MalformedURLException _ ) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\tools\internal\xjc\model\nav\NavigatorImpl.java:245: warning: '_' used as an identifier public Location getFieldLocation(Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\tools\internal\xjc\model\nav\NavigatorImpl.java:249: warning: '_' used as an identifier public Location getMethodLocation(Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:345: warning: '_' used as an identifier public Class onClass(Class c, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:349: warning: '_' used as an identifier public Class onParameterizdType(ParameterizedType p, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:354: warning: '_' used as an identifier public Class onGenericArray(GenericArrayType g, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:360: warning: '_' used as an identifier public Class onVariable(TypeVariable v, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:364: warning: '_' used as an identifier public Class onWildcard(WildcardType w, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\Util.java:46: warning: '_' used as an identifier } catch( SecurityException _ ) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\tools\internal\xjc\reader\internalizer\DOMForest.java:478: warning: '_' used as an identifier } catch (SAXException _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\runtime\LeafBeanInfoImpl.java:89: warning: '_' used as an identifier public final String getElementNamespaceURI(BeanT _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\runtime\LeafBeanInfoImpl.java:93: warning: '_' used as an identifier public final String getElementLocalName(BeanT _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\javax\xml\ws\spi\FactoryFinder.java:199: warning: non-varargs call of varargs method with inexact argument type for last parameter; java.util.Iterator iter = ((Iterable) m.invoke(null, args)).iterator(); ^ cast to Object for a varargs call cast to Object[] for a non-varargs call and to suppress this warning 16 warnings C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\runtime\LeafBeanInfoImpl.java:89: warning: '_' used as an identifier public final String getElementNamespaceURI(BeanT _) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\runtime\LeafBeanInfoImpl.java:93: warning: '_' used as an identifier public final String getElementLocalName(BeanT _) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:345: warning: '_' used as an identifier public Class onClass(Class c, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:349: warning: '_' used as an identifier public Class onParameterizdType(ParameterizedType p, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:354: warning: '_' used as an identifier public Class onGenericArray(GenericArrayType g, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:360: warning: '_' used as an identifier public Class onVariable(TypeVariable v, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:364: warning: '_' used as an identifier public Class onWildcard(WildcardType w, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\tools\internal\xjc\reader\internalizer\DOMForest.java:478: warning: '_' used as an identifier } catch (SAXException _) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\tools\internal\xjc\model\nav\NavigatorImpl.java:245: warning: '_' used as an identifier public Location getFieldLocation(Void _) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\tools\internal\xjc\model\nav\NavigatorImpl.java:249: warning: '_' used as an identifier public Location getMethodLocation(Void _) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\Util.java:46: warning: '_' used as an identifier } catch( SecurityException _ ) { ^ (use of '_' as an identifier might not be supported in future releases) 11 warnings c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\Util.java:46: warning: '_' used as an identifier } catch( SecurityException _ ) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:345: warning: '_' used as an identifier public Class onClass(Class c, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:349: warning: '_' used as an identifier public Class onParameterizdType(ParameterizedType p, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:354: warning: '_' used as an identifier public Class onGenericArray(GenericArrayType g, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:360: warning: '_' used as an identifier public Class onVariable(TypeVariable v, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:364: warning: '_' used as an identifier public Class onWildcard(WildcardType w, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\ws\util\JAXWSUtils.java:128: warning: '_' used as an identifier } catch( MalformedURLException _ ) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\runtime\LeafBeanInfoImpl.java:89: warning: '_' used as an identifier public final String getElementNamespaceURI(BeanT _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\runtime\LeafBeanInfoImpl.java:93: warning: '_' used as an identifier public final String getElementLocalName(BeanT _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\javax\xml\ws\spi\FactoryFinder.java:199: warning: non-varargs call of varargs method with inexact argument type for last parameter; java.util.Iterator iter = ((Iterable) m.invoke(null, args)).iterator(); ^ cast to Object for a varargs call cast to Object[] for a non-varargs call and to suppress this warning 10 warnings c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:345: warning: '_' used as an identifier public Class onClass(Class c, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:349: warning: '_' used as an identifier public Class onParameterizdType(ParameterizedType p, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:354: warning: '_' used as an identifier public Class onGenericArray(GenericArrayType g, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:360: warning: '_' used as an identifier public Class onVariable(TypeVariable v, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:364: warning: '_' used as an identifier public Class onWildcard(WildcardType w, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\Util.java:46: warning: '_' used as an identifier } catch( SecurityException _ ) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\ws\util\JAXWSUtils.java:128: warning: '_' used as an identifier } catch( MalformedURLException _ ) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\runtime\LeafBeanInfoImpl.java:89: warning: '_' used as an identifier public final String getElementNamespaceURI(BeanT _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\runtime\LeafBeanInfoImpl.java:93: warning: '_' used as an identifier public final String getElementLocalName(BeanT _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\javax\xml\ws\spi\FactoryFinder.java:199: warning: non-varargs call of varargs method with inexact argument type for last parameter; java.util.Iterator iter = ((Iterable) m.invoke(null, args)).iterator(); ^ cast to Object for a varargs call cast to Object[] for a non-varargs call and to suppress this warning 10 warnings C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\ws\util\JAXWSUtils.java:128: warning: '_' used as an identifier } catch( MalformedURLException _ ) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:345: warning: '_' used as an identifier public Class onClass(Class c, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:349: warning: '_' used as an identifier public Class onParameterizdType(ParameterizedType p, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:354: warning: '_' used as an identifier public Class onGenericArray(GenericArrayType g, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:360: warning: '_' used as an identifier public Class onVariable(TypeVariable v, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\model\nav\ReflectionNavigator.java:364: warning: '_' used as an identifier public Class onWildcard(WildcardType w, Void _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\Util.java:46: warning: '_' used as an identifier } catch( SecurityException _ ) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\runtime\LeafBeanInfoImpl.java:89: warning: '_' used as an identifier public final String getElementNamespaceURI(BeanT _) { ^ (use of '_' as an identifier might not be supported in future releases) c:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\com\sun\xml\internal\bind\v2\runtime\LeafBeanInfoImpl.java:93: warning: '_' used as an identifier public final String getElementLocalName(BeanT _) { ^ (use of '_' as an identifier might not be supported in future releases) C:\Sun\OpenJDK\utils\config\awt\jaxws\src\share\jaxws_classes\javax\xml\ws\spi\FactoryFinder.java:199: warning: non-varargs call of varargs method with inexact argument type for last parameter; java.util.Iterator iter = ((Iterable) m.invoke(null, args)).iterator(); ^ cast to Object for a varargs call cast to Object[] for a non-varargs call and to suppress this warning 10 warnings bit length overflow code 17 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 17 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 18 bits 7->6 code 4 bits 5->6 bit length overflow code 16 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 11 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 12 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 5 bits 5->6 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 17 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 17 bits 7->6 code 4 bits 5->6 bit length overflow code 3 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 4 bits 5->6 bit length overflow code 17 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 6 bits 5->6 bit length overflow code 18 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 13 bits 7->6 code 4 bits 5->6 bit length overflow code 6 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 6 bits 6->7 bit length overflow code 6 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 12 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 12 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow co bit length overflow code 17 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 17 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 18 bits 7->6 code 4 bits 5->6 bit length overflow code 16 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 11 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 12 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 5 bits 5->6 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 17 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 17 bits 7->6 code 4 bits 5->6 bit length overflow code 3 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 4 bits 5->6 bit length overflow code 17 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 6 bits 5->6 bit length overflow code 18 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 13 bits 7->6 code 4 bits 5->6 bit length overflow code 6 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 6 bits 6->7 bit length overflow code 6 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 16 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 0 bits 6->7 bit length overflow code 12 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 12 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 18 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 4 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 3 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow coMicrosoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. Aliases: Table size 1024 (10 bits), shift 0, max chain depth 3 Classes: Table size 32 (5 bits), shift 1, max chain depth 3 Cache: Table size 32 (5 bits), shift 1, max chain depth 3 [Error] encoded value was less than 0: encode(-8.326673E-17, 5.0, 11.0, 16.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\javax\swing\JSpinner.java:43: error: package sun.util.locale.provider does not exist import sun.util.locale.provider.LocaleProviderAdapter; ^ c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\javax\swing\JSpinner.java:44: error: package sun.util.locale.provider does not exist import sun.util.locale.provider.LocaleResources; ^ c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\javax\swing\JSpinner.java:45: error: package sun.util.locale.provider does not exist import sun.util.locale.provider.LocaleServiceProviderPool; ^ [Error] Encountered Infinity: encode(-0.00877193, 0.0, 7.0, 7.0) bit length overflow code 12 bits 6->7 bit length overflow code 11 bits 6->7 code 4 bits 5->6 [Parsed DTD html32 in 165ms] c:\Sun\OpenJDK\utils\config\awt\build\windows-x86-normal-server-release\jdk\gensrc\java\nio\ByteBuffer.java:1455: error: expected Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output truncated ^ c:\Sun\OpenJDK\utils\config\awt\build\windows-x86-normal-server-release\jdk\gensrc\java\nio\ByteBuffer.java:1455: error: ';' expected Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output truncated ^ c:\Sun\OpenJDK\utils\config\awt\build\windows-x86-normal-server-release\jdk\gensrc\java\nio\ByteBuffer.java:1555: error: expected Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output truncated ^ c:\Sun\OpenJDK\utils\config\awt\build\windows-x86-normal-server-release\jdk\gensrc\java\nio\ByteBuffer.java:1555: error: ';' expected Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output truncated ^ c:\Sun\OpenJDK\utils\config\awt\build\windows-x86-normal-server-release\jdk\gensrc\java\nio\ByteBuffer.java:1655: error: expected Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output truncated ^ c:\Sun\OpenJDK\utils\config\awt\build\windows-x86-normal-server-release\jdk\gensrc\java\nio\ByteBuffer.java:1655: error: ';' expected Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output truncated ^ c:\Sun\OpenJDK\utils\config\awt\build\windows-x86-normal-server-release\jdk\gensrc\java\nio\ByteBuffer.java:1755: error: expected Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output truncated ^ c:\Sun\OpenJDK\utils\config\awt\build\windows-x86-normal-server-release\jdk\gensrc\java\nio\ByteBuffer.java:1755: error: ';' expected Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output truncated ^ c:\Sun\OpenJDK\utils\config\awt\build\windows-x86-normal-server-release\jdk\gensrc\java\nio\ByteBuffer.java:1855: error: expected Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output truncated ^ c:\Sun\OpenJDK\utils\config\awt\build\windows-x86-normal-server-release\jdk\gensrc\java\nio\ByteBuffer.java:1855: error: ';' expected Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output truncated ^ c:\Sun\OpenJDK\utils\config\awt\build\windows-x86-normal-server-release\jdk\gensrc\java\nio\ByteBuffer.java:1955: error: expected Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output truncated ^ c:\Sun\OpenJDK\utils\config\awt\build\windows-x86-normal-server-release\jdk\gensrc\java\nio\ByteBuffer.java:1955: error: ';' expected Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output truncated ^ c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\java\nio\charset\Charset.java:28: error: cannot access ByteBuffer import java.nio.ByteBuffer; ^ bad source file: c:\Sun\OpenJDK\utils\config\awt\build\windows-x86-normal-server-release\jdk\gensrc\java\nio\ByteBuffer.java file does not contain class java.nio.ByteBuffer Please remove or make sure it appears in the correct subdirectory of the sourcepath. c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\java\nio\charset\Charset.java:324: error: cannot find symbol private static CharsetProvider standardProvider = new StandardCharsets(); ^ symbol: class CharsetProvider location: class Charset c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\java\nio\charset\Charset.java:341: error: cannot find symbol private static Iterator providers() { ^ symbol: class Iterator location: class Charset c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\java\nio\charset\Charset.java:341: error: cannot find symbol private static Iterator providers() { ^ symbol: class CharsetProvider location: class Charset c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\java\nio\charset\Charset.java:432: error: cannot find symbol private static CharsetProvider extendedProvider = null; ^ symbol: class CharsetProvider location: class Charset c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\java\nio\charset\Charset.java:550: error: cannot find symbol private static void put(Iterator i, Map m) { ^ symbol: class Iterator location: class Charset c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\java\nio\charset\Charset.java:550: error: cannot find symbol private static void put(Iterator i, Map m) { ^ symbol: class Map location: class Charset c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\java\nio\charset\Charset.java:584: error: cannot find symbol public static SortedMap availableCharsets() { ^ symbol: class SortedMap location: class Charset c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\java\nio\charset\Charset.java:634: error: cannot find symbol private Set aliasSet = null; ^ symbol: class Set location: class Charset c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\java\nio\charset\Charset.java:672: error: cannot find symbol public final Set aliases() { ^ symbol: class Set location: class Charset c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\java\nio\charset\Charset.java:720: error: cannot find symbol public String displayName(Locale locale) { ^ symbol: class Locale location: class Charset c:\Sun\OpenJDK\utils\config\awt\build\windows-x86-normal-server-release\jdk\gensrc\java\nio\charset\CharsetDecoder.java:33: error: cannot access CharBuffer import java.nio.CharBuffer; ^ bad source file: c:\Sun\OpenJDK\utils\config\awt\build\windows-x86-normal-server-release\jdk\gensrc\java\nio\CharBuffer.java file does not contain class java.nio.CharBuffer Please remove or make sure it appears in the correct subdirectory of the sourcepath. make[2]: *** [/cygdrive/c/Sun/OpenJDK/utils/config/awt/build/windows-x86-normal-server-release/jdk/classes/javac_state] Error 127 make[1]: *** [classes-only] Error 2 make: *** [jdk-only] Error 2 -------------- next part -------------- Building Java(TM) for target 'default' in configuration 'windows-x86-normal-serv er-release' ## Starting langtools ## Finished langtools (build time 00:00:02) ## Starting hotspot ## Finished hotspot (build time 00:00:03) ## Starting corba ## Finished corba (build time 00:00:02) ## Starting jaxp ## Finished jaxp (build time 00:00:02) ## Starting jaxws ## Finished jaxws (build time 00:00:03) ## Starting jdk Compiling BUILD_JDK Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output t runcated Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output t runcated Compiling 460 files in 36 packages (com.oracle.jrockit.jfr to com.sun.java.util. jar.pack) The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError: Java heap space at com.sun.tools.javac.util.Position$LineMapImpl.build(Position.java:153 ) at com.sun.tools.javac.util.Position.makeLineMap(Position.java:77) at com.sun.tools.javac.parser.JavaTokenizer.getLineMap(JavaTokenizer.jav a:763) at com.sun.tools.javac.parser.Scanner.getLineMap(Scanner.java:127) at com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacPars er.java:3058) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:634) at com.sun.tools.javac.main.JavaCompiler.complete(JavaCompiler.java:778) at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2464) at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2371) at com.sun.tools.javac.code.Symbol.complete(Symbol.java:426) at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:863) at com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2552) at com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:1694) at com.sun.tools.javac.comp.Resolve.findGlobalType(Resolve.java:1753) at com.sun.tools.javac.comp.Resolve.findType(Resolve.java:1809) at com.sun.tools.javac.comp.Resolve.findIdent(Resolve.java:1834) at com.sun.tools.javac.comp.Resolve.resolveIdent(Resolve.java:2108) at com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:2945) at com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:1969) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:601) at com.sun.tools.javac.comp.Attr.attribType(Attr.java:639) at com.sun.tools.javac.comp.Attr.attribType(Attr.java:632) at com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:1943) at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1491) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:601) at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:619) at com.sun.tools.javac.comp.Attr.visitAssign(Attr.java:2761) at com.sun.tools.javac.tree.JCTree$JCAssign.accept(JCTree.java:1652) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:601) at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:626) at com.sun.tools.javac.comp.Attr.visitExec(Attr.java:1569) at com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.j ava:1271) c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\java\awt\EventDispatchThre ad.java:123: warning: non-varargs call of varargs method with inexact argument t ype for last parameter; final Method evaluateMethod = Class.forName("sun.lwawt.macosx.Ev entDispatchAccess").getMethod("evaluate", null); ^ cast to Class for a varargs call cast to Class[] for a non-varargs call and to suppress this warning c:\Sun\OpenJDK\utils\config\awt\jdk\src\share\classes\java\awt\EventDispatchThre ad.java:126: warning: non-varargs call of varargs method with inexact argument t ype for last parameter; return ((Boolean)evaluateMethod.invoke(cond, null)).bool eanValue(); ^ cast to Object for a varargs call cast to Object[] for a non-varargs call and to suppress this warning make[2]: *** [/cygdrive/c/Sun/OpenJDK/utils/config/awt/build/windows-x86-normal- server-release/jdk/classes/javac_state] Error 127 make[1]: *** [classes-only] Error 2 make: *** [jdk-only] Error 2 From alexandr.scherbatiy at oracle.com Wed Feb 13 13:12:05 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 13 Feb 2013 17:12:05 +0400 Subject: Variable information not available, source compiled without -g option Message-ID: <511B9125.4090201@oracle.com> Hello, I built the OpenJDK from the hg.openjdk.java.net/jdk8/awt on windows 7. Debugging java code does not show JDK method arguments with message: "Variable information not available, source compiled without -g option" I see the warning in the config.log file but probably it relates to the compiling native files: ---------------------------------------------- configure:19912: result: no configure:19921: checking whether /cygdrive/c/progra~2/micros~1.0/vc/bin/cl accepts -g configure:19941: /cygdrive/c/progra~2/micros~1.0/vc/bin/cl -c -g conftest.c >&5 conftest.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. cl : Command line warning D9002 : ignoring unknown option '-g' ---------------------------------------------- Thanks, Alexandr. From alexandr.scherbatiy at oracle.com Wed Feb 13 15:02:42 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 13 Feb 2013 19:02:42 +0400 Subject: Variable information not available, source compiled without -g option In-Reply-To: <511B9125.4090201@oracle.com> References: <511B9125.4090201@oracle.com> Message-ID: <511BAB12.204@oracle.com> I found that I did not use the --enable-debug option. I will try to rebuild my project. Thanks, Alexandr. On 2/13/2013 5:12 PM, Alexander Scherbatiy wrote: > > Hello, > > I built the OpenJDK from the hg.openjdk.java.net/jdk8/awt on > windows 7. > Debugging java code does not show JDK method arguments with message: > "Variable information not available, source compiled without -g option" > > I see the warning in the config.log file but probably it relates to > the compiling native files: > ---------------------------------------------- > configure:19912: result: no > configure:19921: checking whether > /cygdrive/c/progra~2/micros~1.0/vc/bin/cl accepts -g > configure:19941: /cygdrive/c/progra~2/micros~1.0/vc/bin/cl -c -g > conftest.c >&5 > conftest.c > Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 > for 80x86 > Copyright (C) Microsoft Corporation. All rights reserved. > > cl : Command line warning D9002 : ignoring unknown option '-g' > ---------------------------------------------- > > Thanks, > Alexandr. From kelly.ohair at oracle.com Wed Feb 13 16:00:44 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 13 Feb 2013 08:00:44 -0800 (PST) Subject: build JDK 7 Windows 7: make jdk fails building sounds In-Reply-To: <511AE7BB.6030101@oracle.com> References: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> <1AC3281AD57A34468B9879C754022CAF05F1556C9D@exchange.vocera.local> <511A9AF4.60300@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F14@exchange.vocera.local> <511AE216.70309@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F20@exchange.vocera.local> <511AE7BB.6030101@oracle.com> Message-ID: <17771D42-CEE7-4446-A616-6AAF9FABED51@oracle.com> FYI.. I filed a bug on this, it will be fixed. Apparently builds seemed to work without DXSDK used, so someone incorrectly assumed that the DXSDK dependency was no longer needed. A mistake. Getting the antique DirectX SDK is an issue of course, but -kto On Feb 12, 2013, at 5:09 PM, Phil Race wrote: > I am not sure if you mean will it be "fixing" this. > The JDK 8 new build system should not be making any changes to the choice > of library or tools being used here or anywhere else without discussion/consent. > This is a product area specific change which will be handled on 2d-dev with > appropriate product area testing etc. > > -phil. > > On 2/12/2013 4:51 PM, Randy Nielsen wrote: >> MSDN usually keeps old products around a very long time (you can still get Windows 3.1), but the obvious problem for the open source community is that it is not publicly available. >> >> Do you have a perspective on how stable-complete the JDK 8 build is or will be, especially for Windows? >> >> Randy >> >> -----Original Message----- >> From: Phil Race [mailto:philip.race at oracle.com] >> Sent: Tuesday, February 12, 2013 4:45 PM >> To: Randy Nielsen >> Cc: Kelly O'Hair; build-dev at openjdk.java.net >> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >> >> I've filed a bug JDK-8008022 to upgrade to June 2010. >> I'll add your suggestion about Oct 2004 as a workaround but if Microsoft have a rolling removal policy that'll be gone soon too. >> >> -phil. >> >> On 2/12/2013 4:43 PM, Randy Nielsen wrote: >>> Building with DirectX 9 publicly available builds from 2006, the closest I can find to 2004, fails. However with access to a DirectX 9 build only available on MSDN with a login I found a DirectX version from October 2004: dxsdk_oct2004.exe. When I installed this I was finally able to successfully build OpenJDK JDK 7. About time! >>> >>> Unfortunately I can't redistribute this file, but it is available through MSDN. >>> >>> Regards, >>> >>> Randy >>> >>> -----Original Message----- >>> From: Phil Race [mailto:philip.race at oracle.com] >>> Sent: Tuesday, February 12, 2013 11:42 AM >>> To: Randy Nielsen >>> Cc: Kelly O'Hair; build-dev at openjdk.java.net >>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>> >>> I think Microsoft may have recently removed this. >>> Typing "summer 2004 direct x sdk" into google, the top hit is a link to the download location but it is no longer is a valid link. >>> Obviously lots of people already have a copy but I'm not sure if they can redistribute it to you. >>> >>> We specified that one because versions before and afterward were unstable. >>> At least that is what our engineer working on the Direct X pipeline for JDK 6u10 told me. If its no longer available we may need to look into testing a much newer version. June 2010 as we use in FX might be a safe bet. >>> >>> -phil. >>> >>> >>> On 2/12/2013 11:25 AM, Randy Nielsen wrote: >>>> Actually I think this failure is because I accidentally installed two different versions of the windows 7 sdk. I've rebuilt my system and am starting the build again. >>>> >>>> The OpenJDK README does require a specific version of DirectX 9 SDK - the Summer 2004 version. The *problem* is that the Summer 2004 build is not available anywhere - at least I couldn't find it. I settled for August 2006 build, which was the closest I could find. If you or anyone could point me at a link with the 2004 build I'd be grateful. >>>> >>>> For Windows at least the OpenJDK build seems to me to be fraught with difficulties in getting the correct version of tools that work together. Most notable are some Microsoft products (DirectX) and recent versions of Cygwin hanging building Hotspot. The almost impossibility of clean uninstalls of Microsoft products adds to the difficulties here. I'm not sure anything can be done about this, at least for a make system for JDK 7 that is clearly long in the tooth. >>>> >>>> Do you think that the JDK8 build system will be sturdier with Windows? >>>> >>>> Regards, >>>> >>>> Randy >>>> >>>> -----Original Message----- >>>> From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] >>>> Sent: Tuesday, February 12, 2013 11:11 AM >>>> To: Randy Nielsen >>>> Cc: build-dev at openjdk.java.net >>>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>>> >>>> It is my understanding that this is why we require the use of a specific DirectX SDK. >>>> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html >>>> # >>>> dxsdk >>>> >>>> -kto >>>> >>>> >>>> On Feb 8, 2013, at 7:07 PM, Randy Nielsen wrote: >>>> >>>>> "make jdk" fails building JavaX Sounds library in the include file objidl.h. Output is below. The compiler fails trying to use this: "__RPC__out_xcount_part". The web suggests that the fix is obtained by placing your SDK entries before your VC entries in the PATH and the LIB. I've done this but failure is the same. Does anyone have any suggestions? >>>>> >>>>> Randy >>>>> >>>>> Building lib:C:/OpenJDK/openjdk/build/windows-amd64/bin/jsoundds.dll >>>>> "C:/PROGRA~2/MICROS~2.0/Common7/Tools"/../../Vc/bin/amd64/cl -O1 >>>>> -Zi -nologo -M D /D _STATIC_CPPLIB /D >>>>> _DISABLE_DEPRECATE_STATIC_CPPLIB >>>>> -Zc:wchar_t- -FdC:/OpenJ >>>>> DK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundds/obj64/PL >>>>> A >>>>> T >>>>> FORM_API_W inOS_DirectSound.pdb >>>>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sou >>>>> nd/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 -D _CRT_SECURE_ >>>>> NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE -DNDEBUG -DWIN32 -DIAL -D_LITTLE_END >>>>> IAN -D_AMD64_ -Damd64 -DWIN32_LEAN_AND_MEAN -I. >>>>> -IC:/OpenJDK/openjdk/build/windo >>>>> ws-amd64/tmp/sun/javax.sound/jsoundds/CClassHeaders >>>>> -I../../../../src/windows/ja vavm/export -I../../../../src/share/javavm/export -I../../../../src/share/native /common -I../../../../src/windows/native/common -I../../../../src/share/native/j >>>>> avax/sound -I../../../../src/windows/native/javax/sound -DX_PLATFORM=X_WINDOWS >>>>> -DX_ARCH=X_AMD64 -DUSE_DAUDIO=TRUE >>>>> -I../../../../src/share/native/com/sun/media >>>>> /sound -IC:/PROGRA~2/MI4ADD~1/Include -c >>>>> -FoC:/OpenJDK/openjdk/build/windows-am >>>>> d64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.obj ../.. >>>>> /../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_Dir >>>>> e >>>>> c >>>>> tSound.cpp >>>>> >>>>> PLATFORM_API_WinOS_DirectSound.cpp >>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11280) : error C2061: syntax error : >>>>> identifier '__RPC__out_xcount_part' >>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : error C2059: syntax error : >>>>> ')' >>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : fatal error C1903: >>>>> unable to recover from previous error(s); stopping compilation >>>>> make[4]: *** >>>>> [C:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundd >>>>> s/obj64/PLATFORM_API_WinOS_DirectSound.obj] Error 2 >>>>> make[4]: Leaving directory >>>>> `/cygdrive/c/OpenJDK/openjdk/jdk/make/javax/sound/jso > From kelly.ohair at oracle.com Wed Feb 13 16:35:49 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 13 Feb 2013 08:35:49 -0800 Subject: build JDK 7 Windows 7: make jdk fails building sounds In-Reply-To: <17771D42-CEE7-4446-A616-6AAF9FABED51@oracle.com> References: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> <1AC3281AD57A34468B9879C754022CAF05F1556C9D@exchange.vocera.local> <511A9AF4.60300@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F14@exchange.vocera.local> <511AE216.70309@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F20@exchange.vocera.local> <511AE7BB.6030101@oracle.com> <17771D42-CEE7-4446-A616-6AAF9FABED51@oracle.com> Message-ID: <8B93CC32-8306-49A1-81FD-17F4F7268251@oracle.com> On Feb 13, 2013, at 8:00 AM, Kelly O'Hair wrote: > FYI.. > > I filed a bug on this, it will be fixed. Apparently builds seemed to work without DXSDK used, so someone > incorrectly assumed that the DXSDK dependency was no longer needed. A mistake. > > Getting the antique DirectX SDK is an issue of course, but but... Phil is correct that the 2d-dev team should handle this change of DirectX SDK versions. -kto > > -kto > > On Feb 12, 2013, at 5:09 PM, Phil Race wrote: > >> I am not sure if you mean will it be "fixing" this. >> The JDK 8 new build system should not be making any changes to the choice >> of library or tools being used here or anywhere else without discussion/consent. >> This is a product area specific change which will be handled on 2d-dev with >> appropriate product area testing etc. >> >> -phil. >> >> On 2/12/2013 4:51 PM, Randy Nielsen wrote: >>> MSDN usually keeps old products around a very long time (you can still get Windows 3.1), but the obvious problem for the open source community is that it is not publicly available. >>> >>> Do you have a perspective on how stable-complete the JDK 8 build is or will be, especially for Windows? >>> >>> Randy >>> >>> -----Original Message----- >>> From: Phil Race [mailto:philip.race at oracle.com] >>> Sent: Tuesday, February 12, 2013 4:45 PM >>> To: Randy Nielsen >>> Cc: Kelly O'Hair; build-dev at openjdk.java.net >>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>> >>> I've filed a bug JDK-8008022 to upgrade to June 2010. >>> I'll add your suggestion about Oct 2004 as a workaround but if Microsoft have a rolling removal policy that'll be gone soon too. >>> >>> -phil. >>> >>> On 2/12/2013 4:43 PM, Randy Nielsen wrote: >>>> Building with DirectX 9 publicly available builds from 2006, the closest I can find to 2004, fails. However with access to a DirectX 9 build only available on MSDN with a login I found a DirectX version from October 2004: dxsdk_oct2004.exe. When I installed this I was finally able to successfully build OpenJDK JDK 7. About time! >>>> >>>> Unfortunately I can't redistribute this file, but it is available through MSDN. >>>> >>>> Regards, >>>> >>>> Randy >>>> >>>> -----Original Message----- >>>> From: Phil Race [mailto:philip.race at oracle.com] >>>> Sent: Tuesday, February 12, 2013 11:42 AM >>>> To: Randy Nielsen >>>> Cc: Kelly O'Hair; build-dev at openjdk.java.net >>>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>>> >>>> I think Microsoft may have recently removed this. >>>> Typing "summer 2004 direct x sdk" into google, the top hit is a link to the download location but it is no longer is a valid link. >>>> Obviously lots of people already have a copy but I'm not sure if they can redistribute it to you. >>>> >>>> We specified that one because versions before and afterward were unstable. >>>> At least that is what our engineer working on the Direct X pipeline for JDK 6u10 told me. If its no longer available we may need to look into testing a much newer version. June 2010 as we use in FX might be a safe bet. >>>> >>>> -phil. >>>> >>>> >>>> On 2/12/2013 11:25 AM, Randy Nielsen wrote: >>>>> Actually I think this failure is because I accidentally installed two different versions of the windows 7 sdk. I've rebuilt my system and am starting the build again. >>>>> >>>>> The OpenJDK README does require a specific version of DirectX 9 SDK - the Summer 2004 version. The *problem* is that the Summer 2004 build is not available anywhere - at least I couldn't find it. I settled for August 2006 build, which was the closest I could find. If you or anyone could point me at a link with the 2004 build I'd be grateful. >>>>> >>>>> For Windows at least the OpenJDK build seems to me to be fraught with difficulties in getting the correct version of tools that work together. Most notable are some Microsoft products (DirectX) and recent versions of Cygwin hanging building Hotspot. The almost impossibility of clean uninstalls of Microsoft products adds to the difficulties here. I'm not sure anything can be done about this, at least for a make system for JDK 7 that is clearly long in the tooth. >>>>> >>>>> Do you think that the JDK8 build system will be sturdier with Windows? >>>>> >>>>> Regards, >>>>> >>>>> Randy >>>>> >>>>> -----Original Message----- >>>>> From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] >>>>> Sent: Tuesday, February 12, 2013 11:11 AM >>>>> To: Randy Nielsen >>>>> Cc: build-dev at openjdk.java.net >>>>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>>>> >>>>> It is my understanding that this is why we require the use of a specific DirectX SDK. >>>>> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html >>>>> # >>>>> dxsdk >>>>> >>>>> -kto >>>>> >>>>> >>>>> On Feb 8, 2013, at 7:07 PM, Randy Nielsen wrote: >>>>> >>>>>> "make jdk" fails building JavaX Sounds library in the include file objidl.h. Output is below. The compiler fails trying to use this: "__RPC__out_xcount_part". The web suggests that the fix is obtained by placing your SDK entries before your VC entries in the PATH and the LIB. I've done this but failure is the same. Does anyone have any suggestions? >>>>>> >>>>>> Randy >>>>>> >>>>>> Building lib:C:/OpenJDK/openjdk/build/windows-amd64/bin/jsoundds.dll >>>>>> "C:/PROGRA~2/MICROS~2.0/Common7/Tools"/../../Vc/bin/amd64/cl -O1 >>>>>> -Zi -nologo -M D /D _STATIC_CPPLIB /D >>>>>> _DISABLE_DEPRECATE_STATIC_CPPLIB >>>>>> -Zc:wchar_t- -FdC:/OpenJ >>>>>> DK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundds/obj64/PL >>>>>> A >>>>>> T >>>>>> FORM_API_W inOS_DirectSound.pdb >>>>>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sou >>>>>> nd/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 -D _CRT_SECURE_ >>>>>> NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE -DNDEBUG -DWIN32 -DIAL -D_LITTLE_END >>>>>> IAN -D_AMD64_ -Damd64 -DWIN32_LEAN_AND_MEAN -I. >>>>>> -IC:/OpenJDK/openjdk/build/windo >>>>>> ws-amd64/tmp/sun/javax.sound/jsoundds/CClassHeaders >>>>>> -I../../../../src/windows/ja vavm/export -I../../../../src/share/javavm/export -I../../../../src/share/native /common -I../../../../src/windows/native/common -I../../../../src/share/native/j >>>>>> avax/sound -I../../../../src/windows/native/javax/sound -DX_PLATFORM=X_WINDOWS >>>>>> -DX_ARCH=X_AMD64 -DUSE_DAUDIO=TRUE >>>>>> -I../../../../src/share/native/com/sun/media >>>>>> /sound -IC:/PROGRA~2/MI4ADD~1/Include -c >>>>>> -FoC:/OpenJDK/openjdk/build/windows-am >>>>>> d64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.obj ../.. >>>>>> /../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_Dir >>>>>> e >>>>>> c >>>>>> tSound.cpp >>>>>> >>>>>> PLATFORM_API_WinOS_DirectSound.cpp >>>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11280) : error C2061: syntax error : >>>>>> identifier '__RPC__out_xcount_part' >>>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : error C2059: syntax error : >>>>>> ')' >>>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : fatal error C1903: >>>>>> unable to recover from previous error(s); stopping compilation >>>>>> make[4]: *** >>>>>> [C:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundd >>>>>> s/obj64/PLATFORM_API_WinOS_DirectSound.obj] Error 2 >>>>>> make[4]: Leaving directory >>>>>> `/cygdrive/c/OpenJDK/openjdk/jdk/make/javax/sound/jso >> > From kelly.ohair at oracle.com Wed Feb 13 16:45:18 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 13 Feb 2013 08:45:18 -0800 Subject: OpenJDK rebuilding on windows takes a long time In-Reply-To: <511B7B50.3070402@oracle.com> References: <5114ED06.1040802@oracle.com> <51150FB3.7@oracle.com> <5118D476.6030203@oracle.com> <5118DE08.4080709@oracle.com> <511B7B50.3070402@oracle.com> Message-ID: You are pointing at the fastdebug jdk as your boot jdk, why? The official boot jdk for jdk8 is jdk7u7 we cannot guarantee anything else will work, although it should, when tracking down issues like this, you need to narrow down all the possible differences. I have no idea at this time what the 'sync state' is with the awt team forest. My recommendation would be to clone the official jdk8/jdk8 forest, which can be assumed to work since RE should have built it, or any integrator pushing changes into it should have built it. Create 2 forests of so you can do separate experiments on each. Then do the build from the root with a 7u7 jdk in your PATH (no need for the --with-boot-jdk option). Do a build without --enable-sjavac on one forest, then with it on the other. -kto On Feb 13, 2013, at 3:38 AM, Alexander Scherbatiy wrote: > On 2/11/2013 4:03 PM, Erik Joelsson wrote: >> The long term solution to this is sjavac. I do not know if it has made it into that forest yet. You can try by adding --enable-sjavac to configure and do a clean build. If the build works, you have it, and incremental builds will be much faster. > > I tried to use the --enable-sjavac option and JDK 7 and 8 as a boot JDK. > --with-boot-jdk=/cygdrive/c/Sun/Tools/JDK/jdk7/7u14/b10/jdk1.7.0_14/fastdebug --with-target-bits=32 --enable-sjavac > gives compilation error > > --with-boot-jdk=/cygdrive/c/Sun/Tools/JDK/jdk8/b75/jdk1.8.0/fastdebug --with-target-bits=32 --enable-sjavac > gives "OutOfMemoryError: Java heap space" error. > > The log files are attached. > > Thanks, > Alexandr. > >> >> /Erik >> >> On 2013-02-11 12:22, Alexander Scherbatiy wrote: >>> On 2/8/2013 6:46 PM, Erik Joelsson wrote: >>>> Ccache is not supported on windows since it doesn't work with visual studio AFAIK. >>>> >>>> What kind of change did you do? Was it in native code or java and in which repository? >>> I use the http://hg.openjdk.java.net/jdk8/awt repository, edit java code and build the jdk. >>> To reproduce the issue: >>> - open the javax.swing.JFrame class and add a comment line: >>> // a comment >>> - build jdk >>> >>> ----- Build times ------- >>> Start 2013-02-11 15:09:55 >>> End 2013-02-11 15:17:08 >>> 00:00:03 corba >>> 00:00:02 hotspot >>> 00:00:01 jaxp >>> 00:00:03 jaxws >>> 00:06:54 jdk >>> 00:00:02 langtools >>> 00:07:13 TOTAL >>> ------------------------- >>> >>> My environment: >>> OS: Windows 7 Professional, x64 >>> Processor - Intel Core i7 >>> Memory - 8 GB >>> >>> The log file is attached. >>> >>> Thanks, >>> Alexandr. >>>> >>>> /Erik >>>> >>> > > > From aph at redhat.com Wed Feb 13 17:08:11 2013 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Feb 2013 17:08:11 +0000 Subject: Official Boot JDK [Was: OpenJDK rebuilding on windows takes a long time] In-Reply-To: References: <5114ED06.1040802@oracle.com> <51150FB3.7@oracle.com> <5118D476.6030203@oracle.com> <5118DE08.4080709@oracle.com> <511B7B50.3070402@oracle.com> Message-ID: <511BC87B.1070004@redhat.com> On 02/13/2013 04:45 PM, Kelly O'Hair wrote: > The official boot jdk for jdk8 is jdk7u7 we cannot guarantee anything else will work, although it should, Y'know, even I didn't know that. I do now. :-) Andrew. From kelly.ohair at oracle.com Wed Feb 13 17:25:45 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 13 Feb 2013 09:25:45 -0800 Subject: Official Boot JDK [Was: OpenJDK rebuilding on windows takes a long time] In-Reply-To: <511BC87B.1070004@redhat.com> References: <5114ED06.1040802@oracle.com> <51150FB3.7@oracle.com> <5118D476.6030203@oracle.com> <5118DE08.4080709@oracle.com> <511B7B50.3070402@oracle.com> <511BC87B.1070004@redhat.com> Message-ID: <74B6BED5-DC2E-4C34-AB42-608EE2593C41@oracle.com> On Feb 13, 2013, at 9:08 AM, Andrew Haley wrote: > On 02/13/2013 04:45 PM, Kelly O'Hair wrote: >> The official boot jdk for jdk8 is jdk7u7 we cannot guarantee anything else will work, although it should, > > Y'know, even I didn't know that. I do now. :-) > > Andrew. > We moved to 7u7 so that all platforms (including the Mac) would be using the same boot jdk and it was a fairly reliable one on all systems. Changing the boot jdk is not something we like to do very often. We probably failed to advertise this change very well. I'm working on the README-builds.html file now for jdk8, should be pushing in a new version soon. Status is here: http://hg.openjdk.java.net/build-infra/jdk8/raw-file/tip/README-builds.html -kto From rnielsen at vocera.com Wed Feb 13 17:27:41 2013 From: rnielsen at vocera.com (Randy Nielsen) Date: Wed, 13 Feb 2013 09:27:41 -0800 Subject: build JDK 7 Windows 7: make jdk fails building sounds In-Reply-To: <17771D42-CEE7-4446-A616-6AAF9FABED51@oracle.com> References: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> <1AC3281AD57A34468B9879C754022CAF05F1556C9D@exchange.vocera.local> <511A9AF4.60300@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F14@exchange.vocera.local> <511AE216.70309@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F20@exchange.vocera.local> <511AE7BB.6030101@oracle.com> <17771D42-CEE7-4446-A616-6AAF9FABED51@oracle.com> Message-ID: <1AC3281AD57A34468B9879C754022CAF05F15571B4@exchange.vocera.local> The other big problem in the make IMO is that the on 64 bit Window systems Cygwin's current version (and recent versions) hang when building Hotspot. The only "fix" I found was installing an older version of Cygwin (1.6.9) from a Red Hat server: ftp://ftp.ges.redhat.com/private/releng/cygwin-1.6/ I could build Hotspot with this version of Cygwin. While many links to Cygwin claim they will install older versions (cnet.com for example), they invariably point to the generic Cygwin setup.exe program which installs the current version. Randy -----Original Message----- From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] Sent: Wednesday, February 13, 2013 8:01 AM To: Phil Race Cc: Randy Nielsen; build-dev at openjdk.java.net Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds FYI.. I filed a bug on this, it will be fixed. Apparently builds seemed to work without DXSDK used, so someone incorrectly assumed that the DXSDK dependency was no longer needed. A mistake. Getting the antique DirectX SDK is an issue of course, but -kto On Feb 12, 2013, at 5:09 PM, Phil Race wrote: > I am not sure if you mean will it be "fixing" this. > The JDK 8 new build system should not be making any changes to the > choice of library or tools being used here or anywhere else without discussion/consent. > This is a product area specific change which will be handled on 2d-dev > with appropriate product area testing etc. > > -phil. > > On 2/12/2013 4:51 PM, Randy Nielsen wrote: >> MSDN usually keeps old products around a very long time (you can still get Windows 3.1), but the obvious problem for the open source community is that it is not publicly available. >> >> Do you have a perspective on how stable-complete the JDK 8 build is or will be, especially for Windows? >> >> Randy >> >> -----Original Message----- >> From: Phil Race [mailto:philip.race at oracle.com] >> Sent: Tuesday, February 12, 2013 4:45 PM >> To: Randy Nielsen >> Cc: Kelly O'Hair; build-dev at openjdk.java.net >> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >> >> I've filed a bug JDK-8008022 to upgrade to June 2010. >> I'll add your suggestion about Oct 2004 as a workaround but if Microsoft have a rolling removal policy that'll be gone soon too. >> >> -phil. >> >> On 2/12/2013 4:43 PM, Randy Nielsen wrote: >>> Building with DirectX 9 publicly available builds from 2006, the closest I can find to 2004, fails. However with access to a DirectX 9 build only available on MSDN with a login I found a DirectX version from October 2004: dxsdk_oct2004.exe. When I installed this I was finally able to successfully build OpenJDK JDK 7. About time! >>> >>> Unfortunately I can't redistribute this file, but it is available through MSDN. >>> >>> Regards, >>> >>> Randy >>> >>> -----Original Message----- >>> From: Phil Race [mailto:philip.race at oracle.com] >>> Sent: Tuesday, February 12, 2013 11:42 AM >>> To: Randy Nielsen >>> Cc: Kelly O'Hair; build-dev at openjdk.java.net >>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>> >>> I think Microsoft may have recently removed this. >>> Typing "summer 2004 direct x sdk" into google, the top hit is a link to the download location but it is no longer is a valid link. >>> Obviously lots of people already have a copy but I'm not sure if they can redistribute it to you. >>> >>> We specified that one because versions before and afterward were unstable. >>> At least that is what our engineer working on the Direct X pipeline for JDK 6u10 told me. If its no longer available we may need to look into testing a much newer version. June 2010 as we use in FX might be a safe bet. >>> >>> -phil. >>> >>> >>> On 2/12/2013 11:25 AM, Randy Nielsen wrote: >>>> Actually I think this failure is because I accidentally installed two different versions of the windows 7 sdk. I've rebuilt my system and am starting the build again. >>>> >>>> The OpenJDK README does require a specific version of DirectX 9 SDK - the Summer 2004 version. The *problem* is that the Summer 2004 build is not available anywhere - at least I couldn't find it. I settled for August 2006 build, which was the closest I could find. If you or anyone could point me at a link with the 2004 build I'd be grateful. >>>> >>>> For Windows at least the OpenJDK build seems to me to be fraught with difficulties in getting the correct version of tools that work together. Most notable are some Microsoft products (DirectX) and recent versions of Cygwin hanging building Hotspot. The almost impossibility of clean uninstalls of Microsoft products adds to the difficulties here. I'm not sure anything can be done about this, at least for a make system for JDK 7 that is clearly long in the tooth. >>>> >>>> Do you think that the JDK8 build system will be sturdier with Windows? >>>> >>>> Regards, >>>> >>>> Randy >>>> >>>> -----Original Message----- >>>> From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] >>>> Sent: Tuesday, February 12, 2013 11:11 AM >>>> To: Randy Nielsen >>>> Cc: build-dev at openjdk.java.net >>>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>>> >>>> It is my understanding that this is why we require the use of a specific DirectX SDK. >>>> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.ht >>>> ml >>>> # >>>> dxsdk >>>> >>>> -kto >>>> >>>> >>>> On Feb 8, 2013, at 7:07 PM, Randy Nielsen wrote: >>>> >>>>> "make jdk" fails building JavaX Sounds library in the include file objidl.h. Output is below. The compiler fails trying to use this: "__RPC__out_xcount_part". The web suggests that the fix is obtained by placing your SDK entries before your VC entries in the PATH and the LIB. I've done this but failure is the same. Does anyone have any suggestions? >>>>> >>>>> Randy >>>>> >>>>> Building >>>>> lib:C:/OpenJDK/openjdk/build/windows-amd64/bin/jsoundds.dll >>>>> "C:/PROGRA~2/MICROS~2.0/Common7/Tools"/../../Vc/bin/amd64/cl -O1 >>>>> -Zi -nologo -M D /D _STATIC_CPPLIB /D >>>>> _DISABLE_DEPRECATE_STATIC_CPPLIB >>>>> -Zc:wchar_t- -FdC:/OpenJ >>>>> DK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundds/obj64/ >>>>> PL >>>>> A >>>>> T >>>>> FORM_API_W inOS_DirectSound.pdb >>>>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sou >>>>> nd/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 -D _CRT_SECURE_ >>>>> NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE -DNDEBUG -DWIN32 -DIAL -D_LITTLE_END >>>>> IAN -D_AMD64_ -Damd64 -DWIN32_LEAN_AND_MEAN -I. >>>>> -IC:/OpenJDK/openjdk/build/windo >>>>> ws-amd64/tmp/sun/javax.sound/jsoundds/CClassHeaders >>>>> -I../../../../src/windows/ja vavm/export -I../../../../src/share/javavm/export -I../../../../src/share/native /common -I../../../../src/windows/native/common -I../../../../src/share/native/j >>>>> avax/sound -I../../../../src/windows/native/javax/sound -DX_PLATFORM=X_WINDOWS >>>>> -DX_ARCH=X_AMD64 -DUSE_DAUDIO=TRUE >>>>> -I../../../../src/share/native/com/sun/media >>>>> /sound -IC:/PROGRA~2/MI4ADD~1/Include -c >>>>> -FoC:/OpenJDK/openjdk/build/windows-am >>>>> d64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.obj ../.. >>>>> /../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_D >>>>> ir >>>>> e >>>>> c >>>>> tSound.cpp >>>>> >>>>> PLATFORM_API_WinOS_DirectSound.cpp >>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11280) : error C2061: syntax error : >>>>> identifier '__RPC__out_xcount_part' >>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : error C2059: syntax error : >>>>> ')' >>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : fatal error C1903: >>>>> unable to recover from previous error(s); stopping compilation >>>>> make[4]: *** >>>>> [C:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsound >>>>> d s/obj64/PLATFORM_API_WinOS_DirectSound.obj] Error 2 >>>>> make[4]: Leaving directory >>>>> `/cygdrive/c/OpenJDK/openjdk/jdk/make/javax/sound/jso > From kelly.ohair at oracle.com Wed Feb 13 17:34:08 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 13 Feb 2013 09:34:08 -0800 Subject: build JDK 7 Windows 7: make jdk fails building sounds In-Reply-To: <1AC3281AD57A34468B9879C754022CAF05F15571B4@exchange.vocera.local> References: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> <1AC3281AD57A34468B9879C754022CAF05F1556C9D@exchange.vocera.local> <511A9AF4.60300@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F14@exchange.vocera.local> <511AE216.70309@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F20@exchange.vocera.local> <511AE7BB.6030101@oracle.com> <17771D42-CEE7-4446-A616-6AAF9FABED51@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F15571B4@exchange.vocera.local> Message-ID: <4DE36560-A5B0-4B07-B3A5-0C7B426BBE75@oracle.com> We have been successfully using CYGWIN 1.7.16 for a long time, literally on dozens and dozens of systems, Windows XP, 2003, 2008R2, 7, x86 and x64. I have no idea what 1.6 is. We do not recommend CYGWIN 1.5. So where does CYGWIN 1.6.9 come from? -kto On Feb 13, 2013, at 9:27 AM, Randy Nielsen wrote: > The other big problem in the make IMO is that the on 64 bit Window systems Cygwin's current version (and recent versions) hang when building Hotspot. The only "fix" I found was installing an older version of Cygwin (1.6.9) from a Red Hat server: ftp://ftp.ges.redhat.com/private/releng/cygwin-1.6/ I could build Hotspot with this version of Cygwin. > > While many links to Cygwin claim they will install older versions (cnet.com for example), they invariably point to the generic Cygwin setup.exe program which installs the current version. > > Randy > > > -----Original Message----- > From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] > Sent: Wednesday, February 13, 2013 8:01 AM > To: Phil Race > Cc: Randy Nielsen; build-dev at openjdk.java.net > Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds > > FYI.. > > I filed a bug on this, it will be fixed. Apparently builds seemed to work without DXSDK used, so someone incorrectly assumed that the DXSDK dependency was no longer needed. A mistake. > > Getting the antique DirectX SDK is an issue of course, but > > -kto > > On Feb 12, 2013, at 5:09 PM, Phil Race wrote: > >> I am not sure if you mean will it be "fixing" this. >> The JDK 8 new build system should not be making any changes to the >> choice of library or tools being used here or anywhere else without discussion/consent. >> This is a product area specific change which will be handled on 2d-dev >> with appropriate product area testing etc. >> >> -phil. >> >> On 2/12/2013 4:51 PM, Randy Nielsen wrote: >>> MSDN usually keeps old products around a very long time (you can still get Windows 3.1), but the obvious problem for the open source community is that it is not publicly available. >>> >>> Do you have a perspective on how stable-complete the JDK 8 build is or will be, especially for Windows? >>> >>> Randy >>> >>> -----Original Message----- >>> From: Phil Race [mailto:philip.race at oracle.com] >>> Sent: Tuesday, February 12, 2013 4:45 PM >>> To: Randy Nielsen >>> Cc: Kelly O'Hair; build-dev at openjdk.java.net >>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>> >>> I've filed a bug JDK-8008022 to upgrade to June 2010. >>> I'll add your suggestion about Oct 2004 as a workaround but if Microsoft have a rolling removal policy that'll be gone soon too. >>> >>> -phil. >>> >>> On 2/12/2013 4:43 PM, Randy Nielsen wrote: >>>> Building with DirectX 9 publicly available builds from 2006, the closest I can find to 2004, fails. However with access to a DirectX 9 build only available on MSDN with a login I found a DirectX version from October 2004: dxsdk_oct2004.exe. When I installed this I was finally able to successfully build OpenJDK JDK 7. About time! >>>> >>>> Unfortunately I can't redistribute this file, but it is available through MSDN. >>>> >>>> Regards, >>>> >>>> Randy >>>> >>>> -----Original Message----- >>>> From: Phil Race [mailto:philip.race at oracle.com] >>>> Sent: Tuesday, February 12, 2013 11:42 AM >>>> To: Randy Nielsen >>>> Cc: Kelly O'Hair; build-dev at openjdk.java.net >>>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>>> >>>> I think Microsoft may have recently removed this. >>>> Typing "summer 2004 direct x sdk" into google, the top hit is a link to the download location but it is no longer is a valid link. >>>> Obviously lots of people already have a copy but I'm not sure if they can redistribute it to you. >>>> >>>> We specified that one because versions before and afterward were unstable. >>>> At least that is what our engineer working on the Direct X pipeline for JDK 6u10 told me. If its no longer available we may need to look into testing a much newer version. June 2010 as we use in FX might be a safe bet. >>>> >>>> -phil. >>>> >>>> >>>> On 2/12/2013 11:25 AM, Randy Nielsen wrote: >>>>> Actually I think this failure is because I accidentally installed two different versions of the windows 7 sdk. I've rebuilt my system and am starting the build again. >>>>> >>>>> The OpenJDK README does require a specific version of DirectX 9 SDK - the Summer 2004 version. The *problem* is that the Summer 2004 build is not available anywhere - at least I couldn't find it. I settled for August 2006 build, which was the closest I could find. If you or anyone could point me at a link with the 2004 build I'd be grateful. >>>>> >>>>> For Windows at least the OpenJDK build seems to me to be fraught with difficulties in getting the correct version of tools that work together. Most notable are some Microsoft products (DirectX) and recent versions of Cygwin hanging building Hotspot. The almost impossibility of clean uninstalls of Microsoft products adds to the difficulties here. I'm not sure anything can be done about this, at least for a make system for JDK 7 that is clearly long in the tooth. >>>>> >>>>> Do you think that the JDK8 build system will be sturdier with Windows? >>>>> >>>>> Regards, >>>>> >>>>> Randy >>>>> >>>>> -----Original Message----- >>>>> From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] >>>>> Sent: Tuesday, February 12, 2013 11:11 AM >>>>> To: Randy Nielsen >>>>> Cc: build-dev at openjdk.java.net >>>>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>>>> >>>>> It is my understanding that this is why we require the use of a specific DirectX SDK. >>>>> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.ht >>>>> ml >>>>> # >>>>> dxsdk >>>>> >>>>> -kto >>>>> >>>>> >>>>> On Feb 8, 2013, at 7:07 PM, Randy Nielsen wrote: >>>>> >>>>>> "make jdk" fails building JavaX Sounds library in the include file objidl.h. Output is below. The compiler fails trying to use this: "__RPC__out_xcount_part". The web suggests that the fix is obtained by placing your SDK entries before your VC entries in the PATH and the LIB. I've done this but failure is the same. Does anyone have any suggestions? >>>>>> >>>>>> Randy >>>>>> >>>>>> Building >>>>>> lib:C:/OpenJDK/openjdk/build/windows-amd64/bin/jsoundds.dll >>>>>> "C:/PROGRA~2/MICROS~2.0/Common7/Tools"/../../Vc/bin/amd64/cl -O1 >>>>>> -Zi -nologo -M D /D _STATIC_CPPLIB /D >>>>>> _DISABLE_DEPRECATE_STATIC_CPPLIB >>>>>> -Zc:wchar_t- -FdC:/OpenJ >>>>>> DK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundds/obj64/ >>>>>> PL >>>>>> A >>>>>> T >>>>>> FORM_API_W inOS_DirectSound.pdb >>>>>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sou >>>>>> nd/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 -D _CRT_SECURE_ >>>>>> NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE -DNDEBUG -DWIN32 -DIAL -D_LITTLE_END >>>>>> IAN -D_AMD64_ -Damd64 -DWIN32_LEAN_AND_MEAN -I. >>>>>> -IC:/OpenJDK/openjdk/build/windo >>>>>> ws-amd64/tmp/sun/javax.sound/jsoundds/CClassHeaders >>>>>> -I../../../../src/windows/ja vavm/export -I../../../../src/share/javavm/export -I../../../../src/share/native /common -I../../../../src/windows/native/common -I../../../../src/share/native/j >>>>>> avax/sound -I../../../../src/windows/native/javax/sound -DX_PLATFORM=X_WINDOWS >>>>>> -DX_ARCH=X_AMD64 -DUSE_DAUDIO=TRUE >>>>>> -I../../../../src/share/native/com/sun/media >>>>>> /sound -IC:/PROGRA~2/MI4ADD~1/Include -c >>>>>> -FoC:/OpenJDK/openjdk/build/windows-am >>>>>> d64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.obj ../.. >>>>>> /../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_D >>>>>> ir >>>>>> e >>>>>> c >>>>>> tSound.cpp >>>>>> >>>>>> PLATFORM_API_WinOS_DirectSound.cpp >>>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11280) : error C2061: syntax error : >>>>>> identifier '__RPC__out_xcount_part' >>>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : error C2059: syntax error : >>>>>> ')' >>>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : fatal error C1903: >>>>>> unable to recover from previous error(s); stopping compilation >>>>>> make[4]: *** >>>>>> [C:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsound >>>>>> d s/obj64/PLATFORM_API_WinOS_DirectSound.obj] Error 2 >>>>>> make[4]: Leaving directory >>>>>> `/cygdrive/c/OpenJDK/openjdk/jdk/make/javax/sound/jso >> > From volker.simonis at gmail.com Wed Feb 13 18:09:41 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 13 Feb 2013 19:09:41 +0100 Subject: build JDK 7 Windows 7: make jdk fails building sounds In-Reply-To: <4DE36560-A5B0-4B07-B3A5-0C7B426BBE75@oracle.com> References: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> <1AC3281AD57A34468B9879C754022CAF05F1556C9D@exchange.vocera.local> <511A9AF4.60300@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F14@exchange.vocera.local> <511AE216.70309@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F20@exchange.vocera.local> <511AE7BB.6030101@oracle.com> <17771D42-CEE7-4446-A616-6AAF9FABED51@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F15571B4@exchange.vocera.local> <4DE36560-A5B0-4B07-B3A5-0C7B426BBE75@oracle.com> Message-ID: Kelly, are you absolutely sure you really mean "1.7.16" and not "1.7.6"? I think 1.7.16 is quite new so I wonder you are already using it "for a long time". Morover, as discussed in the previous thread (http://mail.openjdk.java.net/pipermail/build-dev/2013-February/thread.html#7936), I'm quite sure that every Cygwin version newer than 1.7.9 hangs pretty reproducible (at least ffor me and for another hand full of people who have reported this). If it really works for you for all the systems you mention you must have some kind of 'magic' setup and we should really find out what makes it so magic:). Regarding RedHat Cygwin 1.6.9 please see my previous post (http://mail.openjdk.java.net/pipermail/build-dev/2013-February/007956.html). On Wed, Feb 13, 2013 at 6:34 PM, Kelly O'Hair wrote: > We have been successfully using CYGWIN 1.7.16 for a long time, literally on dozens and dozens of systems, Windows XP, 2003, 2008R2, 7, x86 and x64. > I have no idea what 1.6 is. > We do not recommend CYGWIN 1.5. > > So where does CYGWIN 1.6.9 come from? > > -kto > > On Feb 13, 2013, at 9:27 AM, Randy Nielsen wrote: > >> The other big problem in the make IMO is that the on 64 bit Window systems Cygwin's current version (and recent versions) hang when building Hotspot. The only "fix" I found was installing an older version of Cygwin (1.6.9) from a Red Hat server: ftp://ftp.ges.redhat.com/private/releng/cygwin-1.6/ I could build Hotspot with this version of Cygwin. >> >> While many links to Cygwin claim they will install older versions (cnet.com for example), they invariably point to the generic Cygwin setup.exe program which installs the current version. >> >> Randy >> >> >> -----Original Message----- >> From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] >> Sent: Wednesday, February 13, 2013 8:01 AM >> To: Phil Race >> Cc: Randy Nielsen; build-dev at openjdk.java.net >> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >> >> FYI.. >> >> I filed a bug on this, it will be fixed. Apparently builds seemed to work without DXSDK used, so someone incorrectly assumed that the DXSDK dependency was no longer needed. A mistake. >> >> Getting the antique DirectX SDK is an issue of course, but >> >> -kto >> >> On Feb 12, 2013, at 5:09 PM, Phil Race wrote: >> >>> I am not sure if you mean will it be "fixing" this. >>> The JDK 8 new build system should not be making any changes to the >>> choice of library or tools being used here or anywhere else without discussion/consent. >>> This is a product area specific change which will be handled on 2d-dev >>> with appropriate product area testing etc. >>> >>> -phil. >>> >>> On 2/12/2013 4:51 PM, Randy Nielsen wrote: >>>> MSDN usually keeps old products around a very long time (you can still get Windows 3.1), but the obvious problem for the open source community is that it is not publicly available. >>>> >>>> Do you have a perspective on how stable-complete the JDK 8 build is or will be, especially for Windows? >>>> >>>> Randy >>>> >>>> -----Original Message----- >>>> From: Phil Race [mailto:philip.race at oracle.com] >>>> Sent: Tuesday, February 12, 2013 4:45 PM >>>> To: Randy Nielsen >>>> Cc: Kelly O'Hair; build-dev at openjdk.java.net >>>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>>> >>>> I've filed a bug JDK-8008022 to upgrade to June 2010. >>>> I'll add your suggestion about Oct 2004 as a workaround but if Microsoft have a rolling removal policy that'll be gone soon too. >>>> >>>> -phil. >>>> >>>> On 2/12/2013 4:43 PM, Randy Nielsen wrote: >>>>> Building with DirectX 9 publicly available builds from 2006, the closest I can find to 2004, fails. However with access to a DirectX 9 build only available on MSDN with a login I found a DirectX version from October 2004: dxsdk_oct2004.exe. When I installed this I was finally able to successfully build OpenJDK JDK 7. About time! >>>>> >>>>> Unfortunately I can't redistribute this file, but it is available through MSDN. >>>>> >>>>> Regards, >>>>> >>>>> Randy >>>>> >>>>> -----Original Message----- >>>>> From: Phil Race [mailto:philip.race at oracle.com] >>>>> Sent: Tuesday, February 12, 2013 11:42 AM >>>>> To: Randy Nielsen >>>>> Cc: Kelly O'Hair; build-dev at openjdk.java.net >>>>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>>>> >>>>> I think Microsoft may have recently removed this. >>>>> Typing "summer 2004 direct x sdk" into google, the top hit is a link to the download location but it is no longer is a valid link. >>>>> Obviously lots of people already have a copy but I'm not sure if they can redistribute it to you. >>>>> >>>>> We specified that one because versions before and afterward were unstable. >>>>> At least that is what our engineer working on the Direct X pipeline for JDK 6u10 told me. If its no longer available we may need to look into testing a much newer version. June 2010 as we use in FX might be a safe bet. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 2/12/2013 11:25 AM, Randy Nielsen wrote: >>>>>> Actually I think this failure is because I accidentally installed two different versions of the windows 7 sdk. I've rebuilt my system and am starting the build again. >>>>>> >>>>>> The OpenJDK README does require a specific version of DirectX 9 SDK - the Summer 2004 version. The *problem* is that the Summer 2004 build is not available anywhere - at least I couldn't find it. I settled for August 2006 build, which was the closest I could find. If you or anyone could point me at a link with the 2004 build I'd be grateful. >>>>>> >>>>>> For Windows at least the OpenJDK build seems to me to be fraught with difficulties in getting the correct version of tools that work together. Most notable are some Microsoft products (DirectX) and recent versions of Cygwin hanging building Hotspot. The almost impossibility of clean uninstalls of Microsoft products adds to the difficulties here. I'm not sure anything can be done about this, at least for a make system for JDK 7 that is clearly long in the tooth. >>>>>> >>>>>> Do you think that the JDK8 build system will be sturdier with Windows? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Randy >>>>>> >>>>>> -----Original Message----- >>>>>> From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] >>>>>> Sent: Tuesday, February 12, 2013 11:11 AM >>>>>> To: Randy Nielsen >>>>>> Cc: build-dev at openjdk.java.net >>>>>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>>>>> >>>>>> It is my understanding that this is why we require the use of a specific DirectX SDK. >>>>>> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.ht >>>>>> ml >>>>>> # >>>>>> dxsdk >>>>>> >>>>>> -kto >>>>>> >>>>>> >>>>>> On Feb 8, 2013, at 7:07 PM, Randy Nielsen wrote: >>>>>> >>>>>>> "make jdk" fails building JavaX Sounds library in the include file objidl.h. Output is below. The compiler fails trying to use this: "__RPC__out_xcount_part". The web suggests that the fix is obtained by placing your SDK entries before your VC entries in the PATH and the LIB. I've done this but failure is the same. Does anyone have any suggestions? >>>>>>> >>>>>>> Randy >>>>>>> >>>>>>> Building >>>>>>> lib:C:/OpenJDK/openjdk/build/windows-amd64/bin/jsoundds.dll >>>>>>> "C:/PROGRA~2/MICROS~2.0/Common7/Tools"/../../Vc/bin/amd64/cl -O1 >>>>>>> -Zi -nologo -M D /D _STATIC_CPPLIB /D >>>>>>> _DISABLE_DEPRECATE_STATIC_CPPLIB >>>>>>> -Zc:wchar_t- -FdC:/OpenJ >>>>>>> DK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundds/obj64/ >>>>>>> PL >>>>>>> A >>>>>>> T >>>>>>> FORM_API_W inOS_DirectSound.pdb >>>>>>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sou >>>>>>> nd/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 -D _CRT_SECURE_ >>>>>>> NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE -DNDEBUG -DWIN32 -DIAL -D_LITTLE_END >>>>>>> IAN -D_AMD64_ -Damd64 -DWIN32_LEAN_AND_MEAN -I. >>>>>>> -IC:/OpenJDK/openjdk/build/windo >>>>>>> ws-amd64/tmp/sun/javax.sound/jsoundds/CClassHeaders >>>>>>> -I../../../../src/windows/ja vavm/export -I../../../../src/share/javavm/export -I../../../../src/share/native /common -I../../../../src/windows/native/common -I../../../../src/share/native/j >>>>>>> avax/sound -I../../../../src/windows/native/javax/sound -DX_PLATFORM=X_WINDOWS >>>>>>> -DX_ARCH=X_AMD64 -DUSE_DAUDIO=TRUE >>>>>>> -I../../../../src/share/native/com/sun/media >>>>>>> /sound -IC:/PROGRA~2/MI4ADD~1/Include -c >>>>>>> -FoC:/OpenJDK/openjdk/build/windows-am >>>>>>> d64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.obj ../.. >>>>>>> /../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_D >>>>>>> ir >>>>>>> e >>>>>>> c >>>>>>> tSound.cpp >>>>>>> >>>>>>> PLATFORM_API_WinOS_DirectSound.cpp >>>>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11280) : error C2061: syntax error : >>>>>>> identifier '__RPC__out_xcount_part' >>>>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : error C2059: syntax error : >>>>>>> ')' >>>>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : fatal error C1903: >>>>>>> unable to recover from previous error(s); stopping compilation >>>>>>> make[4]: *** >>>>>>> [C:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsound >>>>>>> d s/obj64/PLATFORM_API_WinOS_DirectSound.obj] Error 2 >>>>>>> make[4]: Leaving directory >>>>>>> `/cygdrive/c/OpenJDK/openjdk/jdk/make/javax/sound/jso >>> >> > From kelly.ohair at oracle.com Wed Feb 13 18:47:17 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 13 Feb 2013 10:47:17 -0800 Subject: build JDK 7 Windows 7: make jdk fails building sounds In-Reply-To: References: <1AC3281AD57A34468B9879C754022CAF05F1497B4E@exchange.vocera.local> <1AC3281AD57A34468B9879C754022CAF05F1556C9D@exchange.vocera.local> <511A9AF4.60300@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F14@exchange.vocera.local> <511AE216.70309@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F1556F20@exchange.vocera.local> <511AE7BB.6030101@oracle.com> <17771D42-CEE7-4446-A616-6AAF9FABED51@oracle.com> <1AC3281AD57A34468B9879C754022CAF05F15571B4@exchange.vocera.local> <4DE36560-A5B0-4B07-B3A5-0C7B426BBE75@oracle.com> Message-ID: On Feb 13, 2013, at 10:09 AM, Volker Simonis wrote: > Kelly, are you absolutely sure you really mean "1.7.16" and not "1.7.6"? > I think 1.7.16 is quite new so I wonder you are already using it "for > a long time". Well, for at least 3 months, "long time" might be the wrong words, but solidly been used for thousands of builds on Windows XP x86 and Windows 2003 X64 systems. We are not happy with Windows 7 stability, and we are exploring using Windows 2008R2, which is also 7, not sure I completely understand the difference, but in any case, 2008R2 seems to be more stable. So there may be CYGWIN issues with Windows 7 and newer, We had some issues early on in 2003 X64, updated CYGWIN to 1.7.16, things got better, so we bundled up the packages and when we create new systems we use the same 1.7.16 packages so all our systems in our build&test system are the same. We also had some issues with overloading the Windows systems with the new build-infra makefiles (make -jN issues), but after the "images" target was re-written a few months back, we seemed to be past the "images" hangs. It has been my experience that the odds of any arbitrary version of CYGWIN working well is not very good, and you need to be very careful when doing any updates, maybe more so with Windows 7? :^( Most people never change their version of CYGWIN, but most people usually have issues with it too. We are still planning on having MinGW/MSYS as a backup plan, and maybe even more than a backup if CYGWIN continues to be an issue. -kto > > Morover, as discussed in the previous thread > (http://mail.openjdk.java.net/pipermail/build-dev/2013-February/thread.html#7936), > I'm quite sure that every Cygwin version newer than 1.7.9 hangs pretty > reproducible (at least ffor me and for another hand full of people who > have reported this). If it really works for you for all the systems > you mention you must have some kind of 'magic' setup and we should > really find out what makes it so magic:). > > Regarding RedHat Cygwin 1.6.9 please see my previous post > (http://mail.openjdk.java.net/pipermail/build-dev/2013-February/007956.html). > > On Wed, Feb 13, 2013 at 6:34 PM, Kelly O'Hair wrote: >> We have been successfully using CYGWIN 1.7.16 for a long time, literally on dozens and dozens of systems, Windows XP, 2003, 2008R2, 7, x86 and x64. >> I have no idea what 1.6 is. >> We do not recommend CYGWIN 1.5. >> >> So where does CYGWIN 1.6.9 come from? >> >> -kto >> >> On Feb 13, 2013, at 9:27 AM, Randy Nielsen wrote: >> >>> The other big problem in the make IMO is that the on 64 bit Window systems Cygwin's current version (and recent versions) hang when building Hotspot. The only "fix" I found was installing an older version of Cygwin (1.6.9) from a Red Hat server: ftp://ftp.ges.redhat.com/private/releng/cygwin-1.6/ I could build Hotspot with this version of Cygwin. >>> >>> While many links to Cygwin claim they will install older versions (cnet.com for example), they invariably point to the generic Cygwin setup.exe program which installs the current version. >>> >>> Randy >>> >>> >>> -----Original Message----- >>> From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] >>> Sent: Wednesday, February 13, 2013 8:01 AM >>> To: Phil Race >>> Cc: Randy Nielsen; build-dev at openjdk.java.net >>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>> >>> FYI.. >>> >>> I filed a bug on this, it will be fixed. Apparently builds seemed to work without DXSDK used, so someone incorrectly assumed that the DXSDK dependency was no longer needed. A mistake. >>> >>> Getting the antique DirectX SDK is an issue of course, but >>> >>> -kto >>> >>> On Feb 12, 2013, at 5:09 PM, Phil Race wrote: >>> >>>> I am not sure if you mean will it be "fixing" this. >>>> The JDK 8 new build system should not be making any changes to the >>>> choice of library or tools being used here or anywhere else without discussion/consent. >>>> This is a product area specific change which will be handled on 2d-dev >>>> with appropriate product area testing etc. >>>> >>>> -phil. >>>> >>>> On 2/12/2013 4:51 PM, Randy Nielsen wrote: >>>>> MSDN usually keeps old products around a very long time (you can still get Windows 3.1), but the obvious problem for the open source community is that it is not publicly available. >>>>> >>>>> Do you have a perspective on how stable-complete the JDK 8 build is or will be, especially for Windows? >>>>> >>>>> Randy >>>>> >>>>> -----Original Message----- >>>>> From: Phil Race [mailto:philip.race at oracle.com] >>>>> Sent: Tuesday, February 12, 2013 4:45 PM >>>>> To: Randy Nielsen >>>>> Cc: Kelly O'Hair; build-dev at openjdk.java.net >>>>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>>>> >>>>> I've filed a bug JDK-8008022 to upgrade to June 2010. >>>>> I'll add your suggestion about Oct 2004 as a workaround but if Microsoft have a rolling removal policy that'll be gone soon too. >>>>> >>>>> -phil. >>>>> >>>>> On 2/12/2013 4:43 PM, Randy Nielsen wrote: >>>>>> Building with DirectX 9 publicly available builds from 2006, the closest I can find to 2004, fails. However with access to a DirectX 9 build only available on MSDN with a login I found a DirectX version from October 2004: dxsdk_oct2004.exe. When I installed this I was finally able to successfully build OpenJDK JDK 7. About time! >>>>>> >>>>>> Unfortunately I can't redistribute this file, but it is available through MSDN. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Randy >>>>>> >>>>>> -----Original Message----- >>>>>> From: Phil Race [mailto:philip.race at oracle.com] >>>>>> Sent: Tuesday, February 12, 2013 11:42 AM >>>>>> To: Randy Nielsen >>>>>> Cc: Kelly O'Hair; build-dev at openjdk.java.net >>>>>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>>>>> >>>>>> I think Microsoft may have recently removed this. >>>>>> Typing "summer 2004 direct x sdk" into google, the top hit is a link to the download location but it is no longer is a valid link. >>>>>> Obviously lots of people already have a copy but I'm not sure if they can redistribute it to you. >>>>>> >>>>>> We specified that one because versions before and afterward were unstable. >>>>>> At least that is what our engineer working on the Direct X pipeline for JDK 6u10 told me. If its no longer available we may need to look into testing a much newer version. June 2010 as we use in FX might be a safe bet. >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> On 2/12/2013 11:25 AM, Randy Nielsen wrote: >>>>>>> Actually I think this failure is because I accidentally installed two different versions of the windows 7 sdk. I've rebuilt my system and am starting the build again. >>>>>>> >>>>>>> The OpenJDK README does require a specific version of DirectX 9 SDK - the Summer 2004 version. The *problem* is that the Summer 2004 build is not available anywhere - at least I couldn't find it. I settled for August 2006 build, which was the closest I could find. If you or anyone could point me at a link with the 2004 build I'd be grateful. >>>>>>> >>>>>>> For Windows at least the OpenJDK build seems to me to be fraught with difficulties in getting the correct version of tools that work together. Most notable are some Microsoft products (DirectX) and recent versions of Cygwin hanging building Hotspot. The almost impossibility of clean uninstalls of Microsoft products adds to the difficulties here. I'm not sure anything can be done about this, at least for a make system for JDK 7 that is clearly long in the tooth. >>>>>>> >>>>>>> Do you think that the JDK8 build system will be sturdier with Windows? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Randy >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Kelly O'Hair [mailto:kelly.ohair at oracle.com] >>>>>>> Sent: Tuesday, February 12, 2013 11:11 AM >>>>>>> To: Randy Nielsen >>>>>>> Cc: build-dev at openjdk.java.net >>>>>>> Subject: Re: build JDK 7 Windows 7: make jdk fails building sounds >>>>>>> >>>>>>> It is my understanding that this is why we require the use of a specific DirectX SDK. >>>>>>> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.ht >>>>>>> ml >>>>>>> # >>>>>>> dxsdk >>>>>>> >>>>>>> -kto >>>>>>> >>>>>>> >>>>>>> On Feb 8, 2013, at 7:07 PM, Randy Nielsen wrote: >>>>>>> >>>>>>>> "make jdk" fails building JavaX Sounds library in the include file objidl.h. Output is below. The compiler fails trying to use this: "__RPC__out_xcount_part". The web suggests that the fix is obtained by placing your SDK entries before your VC entries in the PATH and the LIB. I've done this but failure is the same. Does anyone have any suggestions? >>>>>>>> >>>>>>>> Randy >>>>>>>> >>>>>>>> Building >>>>>>>> lib:C:/OpenJDK/openjdk/build/windows-amd64/bin/jsoundds.dll >>>>>>>> "C:/PROGRA~2/MICROS~2.0/Common7/Tools"/../../Vc/bin/amd64/cl -O1 >>>>>>>> -Zi -nologo -M D /D _STATIC_CPPLIB /D >>>>>>>> _DISABLE_DEPRECATE_STATIC_CPPLIB >>>>>>>> -Zc:wchar_t- -FdC:/OpenJ >>>>>>>> DK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsoundds/obj64/ >>>>>>>> PL >>>>>>>> A >>>>>>>> T >>>>>>>> FORM_API_W inOS_DirectSound.pdb >>>>>>>> -FmC:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sou >>>>>>>> nd/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 -D _CRT_SECURE_ >>>>>>>> NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE -DNDEBUG -DWIN32 -DIAL -D_LITTLE_END >>>>>>>> IAN -D_AMD64_ -Damd64 -DWIN32_LEAN_AND_MEAN -I. >>>>>>>> -IC:/OpenJDK/openjdk/build/windo >>>>>>>> ws-amd64/tmp/sun/javax.sound/jsoundds/CClassHeaders >>>>>>>> -I../../../../src/windows/ja vavm/export -I../../../../src/share/javavm/export -I../../../../src/share/native /common -I../../../../src/windows/native/common -I../../../../src/share/native/j >>>>>>>> avax/sound -I../../../../src/windows/native/javax/sound -DX_PLATFORM=X_WINDOWS >>>>>>>> -DX_ARCH=X_AMD64 -DUSE_DAUDIO=TRUE >>>>>>>> -I../../../../src/share/native/com/sun/media >>>>>>>> /sound -IC:/PROGRA~2/MI4ADD~1/Include -c >>>>>>>> -FoC:/OpenJDK/openjdk/build/windows-am >>>>>>>> d64/tmp/sun/javax.sound/jsoundds/obj64/PLATFORM_API_WinOS_DirectSound.obj ../.. >>>>>>>> /../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_D >>>>>>>> ir >>>>>>>> e >>>>>>>> c >>>>>>>> tSound.cpp >>>>>>>> >>>>>>>> PLATFORM_API_WinOS_DirectSound.cpp >>>>>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11280) : error C2061: syntax error : >>>>>>>> identifier '__RPC__out_xcount_part' >>>>>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : error C2059: syntax error : >>>>>>>> ')' >>>>>>>> C:\MSSDKWIN7\Windows\v7.1\Include\objidl.h(11281) : fatal error C1903: >>>>>>>> unable to recover from previous error(s); stopping compilation >>>>>>>> make[4]: *** >>>>>>>> [C:/OpenJDK/openjdk/build/windows-amd64/tmp/sun/javax.sound/jsound >>>>>>>> d s/obj64/PLATFORM_API_WinOS_DirectSound.obj] Error 2 >>>>>>>> make[4]: Leaving directory >>>>>>>> `/cygdrive/c/OpenJDK/openjdk/jdk/make/javax/sound/jso >>>> >>> >> From tim.bell at oracle.com Wed Feb 13 22:35:55 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 13 Feb 2013 14:35:55 -0800 Subject: [7u] Request for approval for CR 8007450 - Add build support for different man pages for OpenJDK and OracleJDK Message-ID: <511C154B.1000104@oracle.com> Requesting approval for these changes in make/common/Release.gmk Adding a total of 8 lines in the open makefile. The OracleJDK pages will be placed in a closed part of the forest. Webrev: http://cr.openjdk.java.net/~erikj/8007450/webrev.jdk.02/ The review thread is here: http://mail.openjdk.java.net/pipermail/build-dev/2013-February/007898.html Thanks- Tim Bell From sean.coffey at oracle.com Thu Feb 14 09:15:12 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 14 Feb 2013 09:15:12 +0000 Subject: [7u] Request for approval for CR 8007450 - Add build support for different man pages for OpenJDK and OracleJDK In-Reply-To: <511C154B.1000104@oracle.com> References: <511C154B.1000104@oracle.com> Message-ID: <511CAB20.4070607@oracle.com> Approved. regards, Sean. On 13/02/2013 22:35, Tim Bell wrote: > Requesting approval for these changes in make/common/Release.gmk > > Adding a total of 8 lines in the open makefile. The OracleJDK pages > will be placed in a closed part of the forest. > > Webrev: > http://cr.openjdk.java.net/~erikj/8007450/webrev.jdk.02/ > > The review thread is here: > http://mail.openjdk.java.net/pipermail/build-dev/2013-February/007898.html > > > > > Thanks- > > Tim Bell > From alexandr.scherbatiy at oracle.com Thu Feb 14 10:24:41 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 14 Feb 2013 14:24:41 +0400 Subject: OpenJDK rebuilding on windows takes a long time In-Reply-To: References: <5114ED06.1040802@oracle.com> <51150FB3.7@oracle.com> <5118D476.6030203@oracle.com> <5118DE08.4080709@oracle.com> <511B7B50.3070402@oracle.com> Message-ID: <511CBB69.3090605@oracle.com> On 2/13/2013 8:45 PM, Kelly O'Hair wrote: > You are pointing at the fastdebug jdk as your boot jdk, why? > > The official boot jdk for jdk8 is jdk7u7 we cannot guarantee anything else will work, although it should, > when tracking down issues like this, you need to narrow down all the possible differences. > > I have no idea at this time what the 'sync state' is with the awt team forest. > My recommendation would be to clone the official jdk8/jdk8 forest, which can be assumed to work since > RE should have built it, or any integrator pushing changes into it should have built it. > Create 2 forests of so you can do separate experiments on each. The question was about time rebuilding JDK after a small change. What time does it take to rebuild the official jdk8/jdk8 forest with default options after small change in the java file like javax.swing.JFrame ? Is sjavac are enabled by default now in the official jdk8/jdk8? If no, what time does it take to rebuild the JDK with the --enable-sjavac option? Thanks, Alexandr. > Then do the build from the root with a 7u7 jdk in your PATH (no need for the --with-boot-jdk option). > Do a build without --enable-sjavac on one forest, then with it on the other. > > -kto > > On Feb 13, 2013, at 3:38 AM, Alexander Scherbatiy wrote: > >> On 2/11/2013 4:03 PM, Erik Joelsson wrote: >>> The long term solution to this is sjavac. I do not know if it has made it into that forest yet. You can try by adding --enable-sjavac to configure and do a clean build. If the build works, you have it, and incremental builds will be much faster. >> I tried to use the --enable-sjavac option and JDK 7 and 8 as a boot JDK. >> --with-boot-jdk=/cygdrive/c/Sun/Tools/JDK/jdk7/7u14/b10/jdk1.7.0_14/fastdebug --with-target-bits=32 --enable-sjavac >> gives compilation error >> >> --with-boot-jdk=/cygdrive/c/Sun/Tools/JDK/jdk8/b75/jdk1.8.0/fastdebug --with-target-bits=32 --enable-sjavac >> gives "OutOfMemoryError: Java heap space" error. >> >> The log files are attached. >> >> Thanks, >> Alexandr. >> >>> /Erik >>> >>> On 2013-02-11 12:22, Alexander Scherbatiy wrote: >>>> On 2/8/2013 6:46 PM, Erik Joelsson wrote: >>>>> Ccache is not supported on windows since it doesn't work with visual studio AFAIK. >>>>> >>>>> What kind of change did you do? Was it in native code or java and in which repository? >>>> I use the http://hg.openjdk.java.net/jdk8/awt repository, edit java code and build the jdk. >>>> To reproduce the issue: >>>> - open the javax.swing.JFrame class and add a comment line: >>>> // a comment >>>> - build jdk >>>> >>>> ----- Build times ------- >>>> Start 2013-02-11 15:09:55 >>>> End 2013-02-11 15:17:08 >>>> 00:00:03 corba >>>> 00:00:02 hotspot >>>> 00:00:01 jaxp >>>> 00:00:03 jaxws >>>> 00:06:54 jdk >>>> 00:00:02 langtools >>>> 00:07:13 TOTAL >>>> ------------------------- >>>> >>>> My environment: >>>> OS: Windows 7 Professional, x64 >>>> Processor - Intel Core i7 >>>> Memory - 8 GB >>>> >>>> The log file is attached. >>>> >>>> Thanks, >>>> Alexandr. >>>>> /Erik >>>>> >> >> From erik.joelsson at oracle.com Thu Feb 14 16:24:45 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Feb 2013 17:24:45 +0100 Subject: Review Request: 8005879: Add -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 to builds on Mac Message-ID: <511D0FCD.4020803@oracle.com> Here are a series of patches that adds the following to all native compile lines on macosx: -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 This is needed to ensure that no macosx APIs newer than version 10.7 are used, and will cause compile time errors if they are. Normally we would just lock down the build platform to avoid such problems, but in this case we can't. Newer mac hardware is not compatible with the older OS versions, forcing us to use newer OS versions on our build systems. The hotspot changes will work independent of the rest and can go through rt as usual. The rest will go into build. If a developer feels the need to disable this feature, the make variable MACOSX_REQUIRED_VERSION can be set to a different version (ex 1080) on the make command line. http://cr.openjdk.java.net/~erikj/8005879/webrev.root.01/ http://cr.openjdk.java.net/~erikj/8005879/webrev.jdk.01/ http://cr.openjdk.java.net/~erikj/8005879/webrev.hotspot.01/ /Erik From kelly.ohair at oracle.com Thu Feb 14 16:36:34 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 14 Feb 2013 08:36:34 -0800 Subject: Review Request: 8005879: Add -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 to builds on Mac In-Reply-To: <511D0FCD.4020803@oracle.com> References: <511D0FCD.4020803@oracle.com> Message-ID: <65AD4F34-04EF-42E7-8BA1-03976979F213@oracle.com> These changes look good to me. -kto On Feb 14, 2013, at 8:24 AM, Erik Joelsson wrote: > Here are a series of patches that adds the following to all native compile lines on macosx: > > -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 > > This is needed to ensure that no macosx APIs newer than version 10.7 are used, and will cause compile time errors if they are. > > Normally we would just lock down the build platform to avoid such problems, but in this case we can't. Newer mac hardware is not compatible with the older OS versions, forcing us to use newer OS versions on our build systems. > > The hotspot changes will work independent of the rest and can go through rt as usual. The rest will go into build. > > If a developer feels the need to disable this feature, the make variable MACOSX_REQUIRED_VERSION can be set to a different version (ex 1080) on the make command line. > > http://cr.openjdk.java.net/~erikj/8005879/webrev.root.01/ > http://cr.openjdk.java.net/~erikj/8005879/webrev.jdk.01/ > http://cr.openjdk.java.net/~erikj/8005879/webrev.hotspot.01/ > > /Erik From david.dehaven at oracle.com Thu Feb 14 17:04:24 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 14 Feb 2013 09:04:24 -0800 Subject: Review Request: 8005879: Add -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 to builds on Mac In-Reply-To: <511D0FCD.4020803@oracle.com> References: <511D0FCD.4020803@oracle.com> Message-ID: <93A5D67B-22E9-4EB7-980E-3C8B3646DE6B@oracle.com> > Here are a series of patches that adds the following to all native compile lines on macosx: > > -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 I know I'm not a reviewer, but I have an opinion anyways :) Using "-mmacosx-version-min=10.7" seems more appropriate for the latter, this is passed to the linker as well which I believe sets version information in the Mach-O headers (in the form of a load command) to prevent it from being loaded on older systems. The MIN_REQUIRED macro is set to a value that matches what's passed to the -mmacosx-version-min argument, so it doesn't need to be provided. -DrD- From mikael.vidstedt at oracle.com Thu Feb 14 17:48:03 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 14 Feb 2013 09:48:03 -0800 Subject: RFR (S): 8007639: Workaround for ccache in vm.make is incorrect In-Reply-To: <511AFBDF.7090705@oracle.com> References: <5115442C.5030309@oracle.com> <51199C9C.9030909@oracle.com> <511AF44F.70401@oracle.com> <511AFB45.6010109@oracle.com> <511AFBDF.7090705@oracle.com> Message-ID: <511D2353.6030209@oracle.com> Erik/David - Thanks for the reviews! Cheers, Mikael On 2/12/2013 6:35 PM, David Holmes wrote: > Looks okay to me. > > David > > On 13/02/2013 12:32 PM, Mikael Vidstedt wrote: >> >> Good catch! There is no fundamental reason for switching to CFLAGS, and >> since the other defines are added to CXXFLAGS so should this. Updated >> webrev here: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.01/webrev/ >> >> Cheers, >> Mikael >> >> On 2013-02-12 18:02, David Holmes wrote: >>> Oops! Hit reply instead of reply-all. Adding back the lists. >>> >>> On 12/02/2013 11:36 AM, David Holmes wrote: >>>> Hi Mikael, >>>> >>>> So after our side-bar discussions on other ways to tackle this, the >>>> only >>>> query I have now is why the original change adjusted CXXFLAGS and this >>>> change adjusts CFLAGS instead? >>>> >>>> Thanks, >>>> David >>>> >>>> On 9/02/2013 4:30 AM, Mikael Vidstedt wrote: >>>>> >>>>> Please review the following change: >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.00/webrev >>>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007639 >>>>> >>>>> This change corrects the workaround that was introduced in vm.make >>>>> for >>>>> enabling ccache for HotSpot builds. The change introduces a file >>>>> specific makefile variable (CFLAGS/) which is used to only >>>>> set >>>>> the JRE_RELEASE_VERSION define when compiling vm_version.o. >>>>> >>>>> Verified manually by observing command lines with/without fix, also >>>>> passes JPRT. >>>>> >>>>> >>>>> Some additional background below, more information is available in >>>>> the >>>>> bug report: >>>>> >>>>> To enable the use of ccache 7132779 [1] introduced some new makefile >>>>> logic in vm.make to only pass the JRE_RELEASE_VERSION define when >>>>> compiling the vm_version.cpp file. The underlying reason for that is >>>>> that the JRE_RELEASE_VERSION can in some cases contain a time >>>>> stamp and >>>>> since ccache checks that the defines match before reusing the cache >>>>> version of the object file that would mean that if the time stamp >>>>> changed all files would have to be recompiled. With the fix only >>>>> vm_version.cpp needs to be recompiled. >>>>> >>>>> This almost works, but the logic introduced in the makefile is >>>>> actually >>>>> incorrect. Today it looks like this: >>>>> >>>>> >>>>> # This is VERY important! The version define must only be supplied to >>>>> vm_version.o >>>>> # If not, ccache will not re-use the cache at all, since the version >>>>> string might contain >>>>> # a time and date. >>>>> vm_version.o: CXXFLAGS += ${JRE_VERSION} >>>>> >>>>> However, the above syntax does not only add the ${JRE_VERSION} to the >>>>> CXXFLAGS of vm_version.o as originally intended - it also /in some >>>>> cases/ adds it to the CXXFLAGS for any and all prerequisites of >>>>> vm_version.o. And vm_version.o depends on all other object files, >>>>> which >>>>> means in theory this actually passes in that potentially time stamped >>>>> version string define to all object files anyway. For various >>>>> reasons in >>>>> reality it only passes it to files that are lexicographically after >>>>> vm_version.o - see bug report for more background on why - but >>>>> there's >>>>> still a handful of files that will be recompiled unnecessarily. >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>> [1] http://bugs.sun.com/view_bug.do?bug_id=7132779 >>>>> >> From Alan.Bateman at oracle.com Thu Feb 14 17:57:38 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Feb 2013 17:57:38 +0000 Subject: 8007436: (profiles) Add JSR-310 to Compact Profiles contents Message-ID: <511D2592.6080608@oracle.com> As David mentioned in another mail, he is hoping to push the profiles work to jdk8/build next week. One update that is needed to the configuration is the changes to take account of ThreeTen (java.time.**). This includes taking into account the ThreeTen updates for M7 that remove the old time zone data (lib/zi), a change that is currently en route from jdk8/tl to master so it will be in before the profiles push. The webrev with the changes (trivial) is here: http://cr.openjdk.java.net/~alanb/8007436/webrev/ Thanks, -Alan. From kelly.ohair at oracle.com Thu Feb 14 18:27:04 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 14 Feb 2013 10:27:04 -0800 Subject: OpenJDK rebuilding on windows takes a long time In-Reply-To: <511CBB69.3090605@oracle.com> References: <5114ED06.1040802@oracle.com> <51150FB3.7@oracle.com> <5118D476.6030203@oracle.com> <5118DE08.4080709@oracle.com> <511B7B50.3070402@oracle.com> <511CBB69.3090605@oracle.com> Message-ID: <8B1ACB3F-1A60-4B80-A895-C870483A2C85@oracle.com> On Feb 14, 2013, at 2:24 AM, Alexander Scherbatiy wrote: > On 2/13/2013 8:45 PM, Kelly O'Hair wrote: >> You are pointing at the fastdebug jdk as your boot jdk, why? >> >> The official boot jdk for jdk8 is jdk7u7 we cannot guarantee anything else will work, although it should, >> when tracking down issues like this, you need to narrow down all the possible differences. >> >> I have no idea at this time what the 'sync state' is with the awt team forest. >> My recommendation would be to clone the official jdk8/jdk8 forest, which can be assumed to work since >> RE should have built it, or any integrator pushing changes into it should have built it. >> Create 2 forests of so you can do separate experiments on each. > The question was about time rebuilding JDK after a small change. And I asked, why are you pointing at a fastdebug JDK for your boot jdk? --with-boot-jdk=/cygdrive/c/Sun/Tools/JDK/jdk7/7u14/b10/jdk1.7.0_14/fastdebug Doesn't matter what the change is, if you use a debug JDK, it will be slow. > > What time does it take to rebuild the official jdk8/jdk8 forest with default options after small change in the java file like javax.swing.JFrame ? You have asked a question that cannot be answered without more data. It depends on dozens of things. What the change is, what the machine is, how many CPUs, how much RAM, how fast is the disk, what else is running on the system, what boot jdk you are using, etc etc. And even if we have that data, the best measure is trying it yourself, everybody's machine will be different. > Is sjavac are enabled by default now in the official jdk8/jdk8? If no, what time does it take to rebuild the JDK with the --enable-sjavac option? sjavac is NOT on by default. Once the langtools team gives us some indication it is ready for primetime, and would be ready to deal with any urgent issues we might encounter, we can do our own experiments, insure RE is ok with the change, and then change the default. In the mean time, developers can turn it on themselves if they want to try it. Again, you are asking "what time does it take" questions that are extremely hard to answer. The expectation is that sjavac might benefit a complete JDK rebuild a little, but that the big benefit with sjavac will be developers making just a few changes. But again, there are too many variables involved to give you an absolute number. -kto > > Thanks, > Alexandr. > >> Then do the build from the root with a 7u7 jdk in your PATH (no need for the --with-boot-jdk option). >> Do a build without --enable-sjavac on one forest, then with it on the other. >> >> -kto >> >> On Feb 13, 2013, at 3:38 AM, Alexander Scherbatiy wrote: >> >>> On 2/11/2013 4:03 PM, Erik Joelsson wrote: >>>> The long term solution to this is sjavac. I do not know if it has made it into that forest yet. You can try by adding --enable-sjavac to configure and do a clean build. If the build works, you have it, and incremental builds will be much faster. >>> I tried to use the --enable-sjavac option and JDK 7 and 8 as a boot JDK. >>> --with-boot-jdk=/cygdrive/c/Sun/Tools/JDK/jdk7/7u14/b10/jdk1.7.0_14/fastdebug --with-target-bits=32 --enable-sjavac >>> gives compilation error >>> >>> --with-boot-jdk=/cygdrive/c/Sun/Tools/JDK/jdk8/b75/jdk1.8.0/fastdebug --with-target-bits=32 --enable-sjavac >>> gives "OutOfMemoryError: Java heap space" error. >>> >>> The log files are attached. >>> >>> Thanks, >>> Alexandr. >>> >>>> /Erik >>>> >>>> On 2013-02-11 12:22, Alexander Scherbatiy wrote: >>>>> On 2/8/2013 6:46 PM, Erik Joelsson wrote: >>>>>> Ccache is not supported on windows since it doesn't work with visual studio AFAIK. >>>>>> >>>>>> What kind of change did you do? Was it in native code or java and in which repository? >>>>> I use the http://hg.openjdk.java.net/jdk8/awt repository, edit java code and build the jdk. >>>>> To reproduce the issue: >>>>> - open the javax.swing.JFrame class and add a comment line: >>>>> // a comment >>>>> - build jdk >>>>> >>>>> ----- Build times ------- >>>>> Start 2013-02-11 15:09:55 >>>>> End 2013-02-11 15:17:08 >>>>> 00:00:03 corba >>>>> 00:00:02 hotspot >>>>> 00:00:01 jaxp >>>>> 00:00:03 jaxws >>>>> 00:06:54 jdk >>>>> 00:00:02 langtools >>>>> 00:07:13 TOTAL >>>>> ------------------------- >>>>> >>>>> My environment: >>>>> OS: Windows 7 Professional, x64 >>>>> Processor - Intel Core i7 >>>>> Memory - 8 GB >>>>> >>>>> The log file is attached. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> /Erik >>>>>> >>> >>> > From sadhak001 at gmail.com Thu Feb 14 19:09:58 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Thu, 14 Feb 2013 19:09:58 +0000 Subject: Hotspot - kind of build and how to detect? Message-ID: Hi, I had asked a query [1] long ago in line with the different builds types when build the OpenJDK project or sub-projects. I have another query related to it - i.e. is there a way to determine what type of build you are currently configured for? Is there an OS environment variable that contains one of the following after we run configure: debug fastdebug generated jvmg optimized product profiles My other query with regards to the folder '* linux-x86_64-normal-server-release*/' under the main /build folder. The naming is OS, CPU and other factors dependant, is there a way to determine through an OS environment variable or through calling a script what name the folder would get when a build was successful? Any suggestions leading to answers to the above would be highly appreciated. Thanks. Cheers mani [1] http://www.mail-archive.com/build-dev at openjdk.java.net/msg07325.html -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate *Meet-a-Project:* https://github.com/MutabilityDetector *Come to Devoxx UK 2013:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From peter.brunet at oracle.com Thu Feb 14 20:32:16 2013 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 14 Feb 2013 14:32:16 -0600 Subject: recent problems with JFX ant script Message-ID: <511D49D0.9010205@oracle.com> I ran into two new problems building JFX on Win 7 this week: 1) I had to unset lowercase tmp and temp. Apparently there is a new problem with having duplicates, TMP/tmp and TEMP/temp. This may be related to http://www.cmake.org/Bug/print_bug_page.php?bug_id=13131 The failure appeared as: launcher-win: [echo] STARTING: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.com native/windows [echo] C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.com /build Release|Win32 IconSwap.vcxproj [exec] [exec] Microsoft (R) Visual Studio Version 10.0.30319.1. [exec] Copyright (coffee) Microsoft Corp. All rights reserved. [exec] 1>------ Build started: Project: IconSwap, Configuration: Release Win32 ------ [exec] 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(147,5): error MSB6001: Invalid command line switch for "CL.exe". Item has already been added. Key in dictionary: 'tmp' Key being added: 'TMP' [exec] ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped === 2) DEVENVDIR somehow gets unset. I had to rerun vsvars.sh to fix it. This failure appeared as: needs-devenv: [echo] Using C:\Users\Pete\JavaFX\controls-RT-26343\jfx\rt-closed\glass\glass-mat-lib-windows\${windows.vs.DEVENVCMD}. BUILD FAILED Both of these showed up when building on Windows 7 which I haven't done in a while. I was just rerunning the ant script over and over after source code changes. I use ant -Dhudson.jfx.job.name=8.0-controls-scrum sdk-no-docs Since the problem is intermittent I supposed these could be related to the combination of cygwin/Norton360. I'll disable Norton auto-protect for a while to see if that helps, but wanted to let others know of this in case it's helpful. Pete From kelly.ohair at oracle.com Thu Feb 14 21:39:50 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 14 Feb 2013 13:39:50 -0800 Subject: recent problems with JFX ant script In-Reply-To: <511D49D0.9010205@oracle.com> References: <511D49D0.9010205@oracle.com> Message-ID: <3FA2B85E-EFEA-4AB0-A5D6-240C21B09D78@oracle.com> There are known conflicts with TMP, TEMP, and TMPDIR with many Windows tools. Having both upper and lowercase names is an additional complication. Worse is that some tools want paths that are pure Windows, like C:\temp, some will accept C:/temp, and some might expect their own path style, like /cygdrive/c/temp In addition, some tools interpret this as a user specific path, and some consider it a global area, like /tmp or /var/tmp. It's also important that whatever path it is, that it exists and is writeable. With VS2010, having TMP not acceptably set might break compilations, or worse let compilations work but not let devenv.exe work, some kind of license issue. So TMP/TEMP/TMPDIR is a mess. "And now you know the rest of the story" -Paul Harvey http://en.wikipedia.org/wiki/The_Rest_of_the_Story ;^) -kto On Feb 14, 2013, at 12:32 PM, Pete Brunet wrote: > I ran into two new problems building JFX on Win 7 this week: > > 1) I had to unset lowercase tmp and temp. Apparently there is a new > problem with having duplicates, TMP/tmp and TEMP/temp. This may be > related to http://www.cmake.org/Bug/print_bug_page.php?bug_id=13131 > > The failure appeared as: > > launcher-win: > [echo] STARTING: C:\Program Files (x86)\Microsoft Visual Studio > 10.0\Common7\IDE\devenv.com native/windows > [echo] C:\Program Files (x86)\Microsoft Visual Studio > 10.0\Common7\IDE\devenv.com /build Release|Win32 IconSwap.vcxproj > [exec] > [exec] Microsoft (R) Visual Studio Version 10.0.30319.1. > [exec] Copyright (coffee) Microsoft Corp. All rights reserved. > [exec] 1>------ Build started: Project: IconSwap, Configuration: > Release Win32 ------ > [exec] 1>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(147,5): > error MSB6001: Invalid command line switch for "CL.exe". Item has > already been added. Key in dictionary: 'tmp' Key being added: 'TMP' > [exec] ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 > skipped === > > 2) DEVENVDIR somehow gets unset. I had to rerun vsvars.sh to fix it. > > This failure appeared as: > > needs-devenv: > [echo] Using > C:\Users\Pete\JavaFX\controls-RT-26343\jfx\rt-closed\glass\glass-mat-lib-windows\${windows.vs.DEVENVCMD}. > > BUILD FAILED > > Both of these showed up when building on Windows 7 which I haven't done > in a while. I was just rerunning the ant script over and over after > source code changes. I use ant -Dhudson.jfx.job.name=8.0-controls-scrum > sdk-no-docs > > Since the problem is intermittent I supposed these could be related to > the combination of cygwin/Norton360. I'll disable Norton auto-protect > for a while to see if that helps, but wanted to let others know of this > in case it's helpful. > > Pete From sadhak001 at gmail.com Fri Feb 15 00:55:56 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 15 Feb 2013 00:55:56 +0000 Subject: Hotspot - kind of build and how to detect? In-Reply-To: References: Message-ID: Hi all again, I did some searching in the OpenJDK folders and found the below notations: *$(CONF_NAME)* in the below line in one of the make files: @$(PRINTF) "Building $(PRODUCT_NAME) for target '$(call GetRealTarget)' in configuration '$(CONF_NAME)'\n\n" And the below from another one: *$(OSNAME)_$(BUILDARCH)_compiler2* *$(OUTPUTDIR)/$(VM_PLATFORM)_compiler2* How could we parse these outside the make file to get some value that I could use (provided we have run configure). Do these flags expect other flags to be set before they can be parsed? Thanks. Cheers, mani On Thu, Feb 14, 2013 at 7:09 PM, Mani Sarkar wrote: > Hi, > > I had asked a query [1] long ago in line with the different builds types > when build the OpenJDK project or sub-projects. I have another query > related to it - i.e. is there a way to determine what type of build you are > currently configured for? Is there an OS environment variable that contains > one of the following after we run configure: > > debug > fastdebug > generated > jvmg > optimized > product > profiles > > > My other query with regards to the folder '* > linux-x86_64-normal-server-release*/' under the main /build folder. The > naming is OS, CPU and other factors dependant, is there a way to determine > through an OS environment variable or through calling a script what name > the folder would get when a build was successful? > > Any suggestions leading to answers to the above would be highly > appreciated. > > Thanks. > > Cheers > mani > [1] http://www.mail-archive.com/build-dev at openjdk.java.net/msg07325.html > -- > *Twitter:* @theNeomatrix369 > *Blog:* http://neomatrix369.wordpress.com > *JUG activity:* LJC Advocate > *Meet-a-Project:* https://github.com/MutabilityDetector > *Come to Devoxx UK 2013:* http://www.devoxx.com/display/UK13/Home > > *Don't chase success, rather aim for "Excellence", and success will come > chasing after you!* > -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate *Meet-a-Project:* https://github.com/MutabilityDetector *Come to Devoxx UK 2013:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From ioi.lam at oracle.com Fri Feb 15 02:04:29 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 14 Feb 2013 18:04:29 -0800 Subject: OpenJDK rebuilding on windows takes a long time In-Reply-To: <511CBB69.3090605@oracle.com> References: <5114ED06.1040802@oracle.com> <51150FB3.7@oracle.com> <5118D476.6030203@oracle.com> <5118DE08.4080709@oracle.com> <511B7B50.3070402@oracle.com> <511CBB69.3090605@oracle.com> Message-ID: <511D97AD.4090309@oracle.com> On 02/14/2013 02:24 AM, Alexander Scherbatiy wrote: > On 2/13/2013 8:45 PM, Kelly O'Hair wrote: >> You are pointing at the fastdebug jdk as your boot jdk, why? >> >> The official boot jdk for jdk8 is jdk7u7 we cannot guarantee anything >> else will work, although it should, >> when tracking down issues like this, you need to narrow down all the >> possible differences. >> >> I have no idea at this time what the 'sync state' is with the awt >> team forest. >> My recommendation would be to clone the official jdk8/jdk8 forest, >> which can be assumed to work since >> RE should have built it, or any integrator pushing changes into it >> should have built it. >> Create 2 forests of so you can do separate experiments on each. > The question was about time rebuilding JDK after a small change. > > What time does it take to rebuild the official jdk8/jdk8 forest > with default options after small change in the java file like > javax.swing.JFrame ? FYI: I am running on Oracle Enterprise Linux 5.0 with official jdk1.7.0_09 as my boot jdk. It's a virtual host with Xeon E5-2690 (only 2 cores allocated) and 12 GB RAM. JDK sources is put on local disk. A one-liner change in URLClassLoader.java takes about 4 minutes. I didn't specify sjavac when running configure. ----- Build times ------- Start 2013-02-14 12:12:14 End 2013-02-14 12:16:13 00:00:00 corba 00:00:01 demos 00:00:12 hotspot 00:00:23 images 00:00:00 jaxp 00:00:00 jaxws 00:03:23 jdk 00:00:00 langtools 00:03:59 TOTAL ------------------------- Finished building Java(TM) for target 'images' Is there an option in the makefiles to compile ONLY the .java file that's changed (assuming I know the changes won't affect other classes)? - Ioi > Is sjavac are enabled by default now in the official jdk8/jdk8? > If no, what time does it take to rebuild the JDK with the > --enable-sjavac option? > > Thanks, > Alexandr. > >> Then do the build from the root with a 7u7 jdk in your PATH (no need >> for the --with-boot-jdk option). >> Do a build without --enable-sjavac on one forest, then with it on the >> other. >> >> -kto >> >> On Feb 13, 2013, at 3:38 AM, Alexander Scherbatiy wrote: >> >>> On 2/11/2013 4:03 PM, Erik Joelsson wrote: >>>> The long term solution to this is sjavac. I do not know if it has >>>> made it into that forest yet. You can try by adding --enable-sjavac >>>> to configure and do a clean build. If the build works, you have it, >>>> and incremental builds will be much faster. >>> I tried to use the --enable-sjavac option and JDK 7 and 8 as a >>> boot JDK. >>> --with-boot-jdk=/cygdrive/c/Sun/Tools/JDK/jdk7/7u14/b10/jdk1.7.0_14/fastdebug >>> --with-target-bits=32 --enable-sjavac >>> gives compilation error >>> >>> --with-boot-jdk=/cygdrive/c/Sun/Tools/JDK/jdk8/b75/jdk1.8.0/fastdebug --with-target-bits=32 >>> --enable-sjavac >>> gives "OutOfMemoryError: Java heap space" error. >>> >>> The log files are attached. >>> >>> Thanks, >>> Alexandr. >>> >>>> /Erik >>>> >>>> On 2013-02-11 12:22, Alexander Scherbatiy wrote: >>>>> On 2/8/2013 6:46 PM, Erik Joelsson wrote: >>>>>> Ccache is not supported on windows since it doesn't work with >>>>>> visual studio AFAIK. >>>>>> >>>>>> What kind of change did you do? Was it in native code or java and >>>>>> in which repository? >>>>> I use the http://hg.openjdk.java.net/jdk8/awt repository, edit >>>>> java code and build the jdk. >>>>> To reproduce the issue: >>>>> - open the javax.swing.JFrame class and add a comment line: >>>>> // a comment >>>>> - build jdk >>>>> >>>>> ----- Build times ------- >>>>> Start 2013-02-11 15:09:55 >>>>> End 2013-02-11 15:17:08 >>>>> 00:00:03 corba >>>>> 00:00:02 hotspot >>>>> 00:00:01 jaxp >>>>> 00:00:03 jaxws >>>>> 00:06:54 jdk >>>>> 00:00:02 langtools >>>>> 00:07:13 TOTAL >>>>> ------------------------- >>>>> >>>>> My environment: >>>>> OS: Windows 7 Professional, x64 >>>>> Processor - Intel Core i7 >>>>> Memory - 8 GB >>>>> >>>>> The log file is attached. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> /Erik >>>>>> >>> >>> > From david.holmes at oracle.com Fri Feb 15 06:59:34 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Feb 2013 16:59:34 +1000 Subject: Hotspot - kind of build and how to detect? In-Reply-To: References: Message-ID: <511DDCD6.9030905@oracle.com> On 15/02/2013 5:09 AM, Mani Sarkar wrote: > I had asked a query [1] long ago in line with the different builds types > when build the OpenJDK project or sub-projects. I have another query > related to it - i.e. is there a way to determine what type of build you are > currently configured for? Is there an OS environment variable that contains > one of the following after we run configure: > > debug > fastdebug > generated > jvmg > optimized > product > profiles (generated is not a type of build) The spec.gmk and hotspot-spec.gmk files in the build directory will tell you somethings. spec.gmk has for example: # using 'configure --with-jdk-variant=normal --with-jvm-variants=client,server --with-target-bits=32 --with-cups-include=/ java/devtools/share/cups/include/ --with-debug-level=release --disable-ccache' and BUILD_VARIANT_RELEASE hotspot-spec.gmk has for example: # Legacy setting: OPT or DBG VARIANT:=OPT # Legacy setting: true or false FASTDEBUG:=false but I don't think you can configure all possibilities here. I think some choices are still influenced by environment variables. > My other query with regards to the folder '* > linux-x86_64-normal-server-release*/' under the main /build folder. The > naming is OS, CPU and other factors dependant, is there a way to determine > through an OS environment variable or through calling a script what name > the folder would get when a build was successful? Determine or define? I always control the above by creating the output directory I want and then cd into it and run configure. David ----- > Any suggestions leading to answers to the above would be highly appreciated. > > Thanks. > > Cheers > mani > [1] http://www.mail-archive.com/build-dev at openjdk.java.net/msg07325.html > From david.holmes at oracle.com Fri Feb 15 07:06:12 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Feb 2013 17:06:12 +1000 Subject: Hotspot - kind of build and how to detect? In-Reply-To: References: Message-ID: <511DDE64.2030505@oracle.com> On 15/02/2013 10:55 AM, Mani Sarkar wrote: > Hi all again, > > I did some searching in the OpenJDK folders and found the below notations: > > *$(CONF_NAME)* in the below line in one of the make files: > @$(PRINTF) "Building $(PRODUCT_NAME) for target '$(call GetRealTarget)' in > configuration '$(CONF_NAME)'\n\n" You can name a configuration anything you want. There is a configure option for it --with-conf-name > And the below from another one: > *$(OSNAME)_$(BUILDARCH)_compiler2* > *$(OUTPUTDIR)/$(VM_PLATFORM)_compiler2* > > How could we parse these outside the make file to get some value that I > could use (provided we have run configure). Do these flags expect other > flags to be set before they can be parsed? I'm not quite sure what you are asking. David > Thanks. > > Cheers, > mani > > On Thu, Feb 14, 2013 at 7:09 PM, Mani Sarkar wrote: > >> Hi, >> >> I had asked a query [1] long ago in line with the different builds types >> when build the OpenJDK project or sub-projects. I have another query >> related to it - i.e. is there a way to determine what type of build you are >> currently configured for? Is there an OS environment variable that contains >> one of the following after we run configure: >> >> debug >> fastdebug >> generated >> jvmg >> optimized >> product >> profiles >> >> >> My other query with regards to the folder '* >> linux-x86_64-normal-server-release*/' under the main /build folder. The >> naming is OS, CPU and other factors dependant, is there a way to determine >> through an OS environment variable or through calling a script what name >> the folder would get when a build was successful? >> >> Any suggestions leading to answers to the above would be highly >> appreciated. >> >> Thanks. >> >> Cheers >> mani >> [1] http://www.mail-archive.com/build-dev at openjdk.java.net/msg07325.html >> -- >> *Twitter:* @theNeomatrix369 >> *Blog:* http://neomatrix369.wordpress.com >> *JUG activity:* LJC Advocate >> *Meet-a-Project:* https://github.com/MutabilityDetector >> *Come to Devoxx UK 2013:* http://www.devoxx.com/display/UK13/Home >> >> *Don't chase success, rather aim for "Excellence", and success will come >> chasing after you!* >> > > > From david.holmes at oracle.com Fri Feb 15 07:24:39 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Feb 2013 17:24:39 +1000 Subject: 8007436: (profiles) Add JSR-310 to Compact Profiles contents In-Reply-To: <511D2592.6080608@oracle.com> References: <511D2592.6080608@oracle.com> Message-ID: <511DE2B7.20409@oracle.com> On 15/02/2013 3:57 AM, Alan Bateman wrote: > > As David mentioned in another mail, he is hoping to push the profiles > work to jdk8/build next week. One update that is needed to the > configuration is the changes to take account of ThreeTen (java.time.**). > This includes taking into account the ThreeTen updates for M7 that > remove the old time zone data (lib/zi), a change that is currently en > route from jdk8/tl to master so it will be in before the profiles push. > The webrev with the changes (trivial) is here: > > http://cr.openjdk.java.net/~alanb/8007436/webrev/ Thanks Alan, looks good to me. Great to see all those zi entries disappear! David > Thanks, > > -Alan. > From oehrstroem at gmail.com Fri Feb 15 07:31:31 2013 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Fri, 15 Feb 2013 08:31:31 +0100 Subject: OpenJDK rebuilding on windows takes a long time In-Reply-To: <511D97AD.4090309@oracle.com> References: <5114ED06.1040802@oracle.com> <51150FB3.7@oracle.com> <5118D476.6030203@oracle.com> <5118DE08.4080709@oracle.com> <511B7B50.3070402@oracle.com> <511CBB69.3090605@oracle.com> <511D97AD.4090309@oracle.com> Message-ID: 2013/2/15 Ioi Lam : > Is there an option in the makefiles to compile ONLY the .java file that's > changed (assuming I know the changes won't affect other classes)? Yes, configure with --enable-sjavac. Then it will recompile exactly the java files you have touched. And if the public api of the package you changed files in, is changed, then it will recompile all other packages that import from that package. Thus add a public method to java/lang/Object.java, type make, and watch it recompile ~9000 classes. Change private code in an awt class, and it will recompile only that package. Try it! And report how it fares for you! //Fredrik From sadhak001 at gmail.com Fri Feb 15 08:24:05 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 15 Feb 2013 08:24:05 +0000 Subject: Hotspot - kind of build and how to detect? In-Reply-To: <511DDE64.2030505@oracle.com> References: <511DDE64.2030505@oracle.com> Message-ID: Hi David, Thanks for coming back with a response. My apologies for not being very clear on what I'm trying to achieve here. Basically my goal is to be able to populate an environment variable in any OS say in linux, that gives me the location of the any artefact under the build folder. For our case I'll select Hotspot, which would look like the below: export HOTSPOT_BINARY_LOC=$TL_FOREST_FOLDER/build/$OPENJDK_RELEASE_NAME/hotspot/$OS_PLATFORM_COMPILER_FOLDER/$BUILD_TYPE As you can see we have a number of variables here, I have the value of the first one, i.e. $TL_FOREST_FOLDER, how do I determine the values for the four other parts of the path $OPENJDK_RELEASE_NAME $OS_PLATFORM_COMPILER_FOLDER $BUILD_TYPE In my case a typical build path looks like /home/openjdk/sources/jdk8_tl/build/*linux-x86_64-normal-server-release* /hotspot/*linux_amd64_compiler2*/*product*/ So I have three variables which I would like to determine after running configure but before building any project using the make command. Does this make it any clearer? Basically I wish to access the environment variables you create (if it works that way) after the configure command. Thanks. Cheers, Mani On Fri, Feb 15, 2013 at 7:06 AM, David Holmes wrote: > On 15/02/2013 10:55 AM, Mani Sarkar wrote: > >> Hi all again, >> >> I did some searching in the OpenJDK folders and found the below notations: >> >> *$(CONF_NAME)* in the below line in one of the make files: >> >> @$(PRINTF) "Building $(PRODUCT_NAME) for target '$(call GetRealTarget)' in >> configuration '$(CONF_NAME)'\n\n" >> > > You can name a configuration anything you want. There is a configure > option for it --with-conf-name > > And the below from another one: >> *$(OSNAME)_$(BUILDARCH)_**compiler2* >> *$(OUTPUTDIR)/$(VM_PLATFORM)_**compiler2* >> >> >> How could we parse these outside the make file to get some value that I >> could use (provided we have run configure). Do these flags expect other >> flags to be set before they can be parsed? >> > > I'm not quite sure what you are asking. > > David > > Thanks. >> >> Cheers, >> mani >> >> On Thu, Feb 14, 2013 at 7:09 PM, Mani Sarkar wrote: >> >> Hi, >>> >>> I had asked a query [1] long ago in line with the different builds types >>> when build the OpenJDK project or sub-projects. I have another query >>> related to it - i.e. is there a way to determine what type of build you >>> are >>> currently configured for? Is there an OS environment variable that >>> contains >>> one of the following after we run configure: >>> >>> debug >>> fastdebug >>> generated >>> jvmg >>> optimized >>> product >>> profiles >>> >>> >>> My other query with regards to the folder '* >>> linux-x86_64-normal-server-**release*/' under the main /build folder. >>> The >>> >>> naming is OS, CPU and other factors dependant, is there a way to >>> determine >>> through an OS environment variable or through calling a script what name >>> the folder would get when a build was successful? >>> >>> Any suggestions leading to answers to the above would be highly >>> appreciated. >>> >>> Thanks. >>> >>> Cheers >>> mani >>> [1] http://www.mail-archive.com/**build-dev at openjdk.java.net/** >>> msg07325.html >>> -- >>> *Twitter:* @theNeomatrix369 >>> *Blog:* http://neomatrix369.wordpress.**com >>> *JUG activity:* LJC Advocate >>> *Meet-a-Project:* https://github.com/**MutabilityDetector >>> *Come to Devoxx UK 2013:* http://www.devoxx.com/display/**UK13/Home >>> >>> *Don't chase success, rather aim for "Excellence", and success will come >>> chasing after you!* >>> >>> >> >> >> -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate *Meet-a-Project:* https://github.com/MutabilityDetector *Come to Devoxx UK 2013:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From erik.joelsson at oracle.com Fri Feb 15 08:43:19 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Feb 2013 09:43:19 +0100 Subject: Review Request: 8005879: Add -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 to builds on Mac In-Reply-To: <93A5D67B-22E9-4EB7-980E-3C8B3646DE6B@oracle.com> References: <511D0FCD.4020803@oracle.com> <93A5D67B-22E9-4EB7-980E-3C8B3646DE6B@oracle.com> Message-ID: <511DF527.4080208@oracle.com> On 2013-02-14 18:04, David DeHaven wrote: >> Here are a series of patches that adds the following to all native compile lines on macosx: >> >> -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 > I know I'm not a reviewer, but I have an opinion anyways :) > > Using "-mmacosx-version-min=10.7" seems more appropriate for the latter, this is passed to the linker as well which I believe sets version information in the Mach-O headers (in the form of a load command) to prevent it from being loaded on older systems. The MIN_REQUIRED macro is set to a value that matches what's passed to the -mmacosx-version-min argument, so it doesn't need to be provided. > > The effect of the -mmacosx-version-min=10.7 when sent to the linker is to make any calls to newer APIs "softlinked". This means the library will still load fine on the older OS, but the application is responsible for only actually making the newer calls if they are available. This is a good feature if you knowingly want to support multiple versions of the OS and still use features in the newer OS when available. I do not believe we have the need for that and if we ever do, then these parameters will need to change. /Erik From erik.joelsson at oracle.com Fri Feb 15 08:51:30 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Feb 2013 09:51:30 +0100 Subject: recent problems with JFX ant script In-Reply-To: <511D49D0.9010205@oracle.com> References: <511D49D0.9010205@oracle.com> Message-ID: <511DF712.8070001@oracle.com> I have seen the same type of problem building the oracle internal deploy repository. My conclusion is that when building with devenv, it interprets environment variables as case insensitive. Cygwin does not and has both lower and upper case tmp and temp defined. Devenv doesn't like having multiple definitions of the same variable. Now to make things even more complicated, when running devenv, a background processes MSBuild is launched, and it's actually this process that triggers the error. It's left running and may or may not be picked up again when rerunning devenv, which explains the intermittent nature of the problem. Killing all the MSBuild processes in taskmanager and unsetting the lowercase tmp and temp solves the problem. For the javafx build, I would recommend adding tmp= and temp= prior to launching devenv when building in cygwin to have the problem universally solved. This is what I do in build infra. /Erik On 2013-02-14 21:32, Pete Brunet wrote: > I ran into two new problems building JFX on Win 7 this week: > > 1) I had to unset lowercase tmp and temp. Apparently there is a new > problem with having duplicates, TMP/tmp and TEMP/temp. This may be > related to http://www.cmake.org/Bug/print_bug_page.php?bug_id=13131 > > The failure appeared as: > > launcher-win: > [echo] STARTING: C:\Program Files (x86)\Microsoft Visual Studio > 10.0\Common7\IDE\devenv.com native/windows > [echo] C:\Program Files (x86)\Microsoft Visual Studio > 10.0\Common7\IDE\devenv.com /build Release|Win32 IconSwap.vcxproj > [exec] > [exec] Microsoft (R) Visual Studio Version 10.0.30319.1. > [exec] Copyright (coffee) Microsoft Corp. All rights reserved. > [exec] 1>------ Build started: Project: IconSwap, Configuration: > Release Win32 ------ > [exec] 1>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(147,5): > error MSB6001: Invalid command line switch for "CL.exe". Item has > already been added. Key in dictionary: 'tmp' Key being added: 'TMP' > [exec] ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 > skipped === > > 2) DEVENVDIR somehow gets unset. I had to rerun vsvars.sh to fix it. > > This failure appeared as: > > needs-devenv: > [echo] Using > C:\Users\Pete\JavaFX\controls-RT-26343\jfx\rt-closed\glass\glass-mat-lib-windows\${windows.vs.DEVENVCMD}. > > BUILD FAILED > > Both of these showed up when building on Windows 7 which I haven't done > in a while. I was just rerunning the ant script over and over after > source code changes. I use ant -Dhudson.jfx.job.name=8.0-controls-scrum > sdk-no-docs > > Since the problem is intermittent I supposed these could be related to > the combination of cygwin/Norton360. I'll disable Norton auto-protect > for a while to see if that helps, but wanted to let others know of this > in case it's helpful. > > Pete From erik.joelsson at oracle.com Fri Feb 15 08:53:10 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Feb 2013 09:53:10 +0100 Subject: 8007436: (profiles) Add JSR-310 to Compact Profiles contents In-Reply-To: <511DE2B7.20409@oracle.com> References: <511D2592.6080608@oracle.com> <511DE2B7.20409@oracle.com> Message-ID: <511DF776.8040009@oracle.com> On 2013-02-15 08:24, David Holmes wrote: > On 15/02/2013 3:57 AM, Alan Bateman wrote: >> >> As David mentioned in another mail, he is hoping to push the profiles >> work to jdk8/build next week. One update that is needed to the >> configuration is the changes to take account of ThreeTen (java.time.**). >> This includes taking into account the ThreeTen updates for M7 that >> remove the old time zone data (lib/zi), a change that is currently en >> route from jdk8/tl to master so it will be in before the profiles push. >> The webrev with the changes (trivial) is here: >> >> http://cr.openjdk.java.net/~alanb/8007436/webrev/ > > Thanks Alan, looks good to me. Great to see all those zi entries > disappear! > Can't agree more, on both accounts. /Erik From erik.joelsson at oracle.com Fri Feb 15 09:49:05 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Feb 2013 10:49:05 +0100 Subject: Review Request: 8005879: Add -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 to builds on Mac In-Reply-To: <511DF527.4080208@oracle.com> References: <511D0FCD.4020803@oracle.com> <93A5D67B-22E9-4EB7-980E-3C8B3646DE6B@oracle.com> <511DF527.4080208@oracle.com> Message-ID: <511E0491.7070508@oracle.com> On 2013-02-15 09:43, Erik Joelsson wrote: > > On 2013-02-14 18:04, David DeHaven wrote: >>> Here are a series of patches that adds the following to all native >>> compile lines on macosx: >>> >>> -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 >>> -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 >> I know I'm not a reviewer, but I have an opinion anyways :) >> >> Using "-mmacosx-version-min=10.7" seems more appropriate for the >> latter, this is passed to the linker as well which I believe sets >> version information in the Mach-O headers (in the form of a load >> command) to prevent it from being loaded on older systems. The >> MIN_REQUIRED macro is set to a value that matches what's passed to >> the -mmacosx-version-min argument, so it doesn't need to be provided. >> >> > The effect of the -mmacosx-version-min=10.7 when sent to the linker is > to make any calls to newer APIs "softlinked". This means the library > will still load fine on the older OS, but the application is > responsible for only actually making the newer calls if they are > available. This is a good feature if you knowingly want to support > multiple versions of the OS and still use features in the newer OS > when available. I do not believe we have the need for that and if we > ever do, then these parameters will need to change. > It's true -mmacosx-version-min= also sets the macro MAC_OS_X_VERSION_MIN_REQUIRED=, but I see no gain in changing just one of them to something else just because it works. The format of the parameter is also different (10.7 vs 1070) which would require us to add logic for converting between the two. /Erik From anthony.petrov at oracle.com Fri Feb 15 10:26:37 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 15 Feb 2013 14:26:37 +0400 Subject: recent problems with JFX ant script In-Reply-To: <511D49D0.9010205@oracle.com> References: <511D49D0.9010205@oracle.com> Message-ID: <511E0D5D.4060103@oracle.com> It's a known issue: http://javafx-jira.kenai.com/browse/RT-27210 -- best regards, Anthony On 2/15/2013 0:32, Pete Brunet wrote: > I ran into two new problems building JFX on Win 7 this week: > > 1) I had to unset lowercase tmp and temp. Apparently there is a new > problem with having duplicates, TMP/tmp and TEMP/temp. This may be > related to http://www.cmake.org/Bug/print_bug_page.php?bug_id=13131 > > The failure appeared as: > > launcher-win: > [echo] STARTING: C:\Program Files (x86)\Microsoft Visual Studio > 10.0\Common7\IDE\devenv.com native/windows > [echo] C:\Program Files (x86)\Microsoft Visual Studio > 10.0\Common7\IDE\devenv.com /build Release|Win32 IconSwap.vcxproj > [exec] > [exec] Microsoft (R) Visual Studio Version 10.0.30319.1. > [exec] Copyright (coffee) Microsoft Corp. All rights reserved. > [exec] 1>------ Build started: Project: IconSwap, Configuration: > Release Win32 ------ > [exec] 1>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(147,5): > error MSB6001: Invalid command line switch for "CL.exe". Item has > already been added. Key in dictionary: 'tmp' Key being added: 'TMP' > [exec] ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 > skipped === > > 2) DEVENVDIR somehow gets unset. I had to rerun vsvars.sh to fix it. > > This failure appeared as: > > needs-devenv: > [echo] Using > C:\Users\Pete\JavaFX\controls-RT-26343\jfx\rt-closed\glass\glass-mat-lib-windows\${windows.vs.DEVENVCMD}. > > BUILD FAILED > > Both of these showed up when building on Windows 7 which I haven't done > in a while. I was just rerunning the ant script over and over after > source code changes. I use ant -Dhudson.jfx.job.name=8.0-controls-scrum > sdk-no-docs > > Since the problem is intermittent I supposed these could be related to > the combination of cygwin/Norton360. I'll disable Norton auto-protect > for a while to see if that helps, but wanted to let others know of this > in case it's helpful. > > Pete From david.holmes at oracle.com Fri Feb 15 10:37:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Feb 2013 20:37:07 +1000 Subject: Hotspot - kind of build and how to detect? In-Reply-To: References: <511DDE64.2030505@oracle.com> Message-ID: <511E0FD3.6070903@oracle.com> On 15/02/2013 6:24 PM, Mani Sarkar wrote: > Hi David, > > Thanks for coming back with a response. My apologies for not being very > clear on what I'm trying to achieve here. > > Basically my goal is to be able to populate an environment variable in > any OS say in linux, that gives me the location of the any artefact > under the build folder. For our case I'll select Hotspot, which would > look like the below: > > export > HOTSPOT_BINARY_LOC=$TL_FOREST_FOLDER/build/$OPENJDK_RELEASE_NAME/hotspot/$OS_PLATFORM_COMPILER_FOLDER/$BUILD_TYPE > > As you can see we have a number of variables here, I have the value of > the first one, i.e. $TL_FOREST_FOLDER, how do I determine the values for > the four other parts of the path > > $OPENJDK_RELEASE_NAME > $OS_PLATFORM_COMPILER_FOLDER > $BUILD_TYPE > > In my case a typical build path looks like > > /home/openjdk/sources/jdk8_tl/build/*linux-x86_64-normal-server-release*/hotspot/*linux_amd64_compiler2*/*product*/ > > So I have three variables which I would like to determine after running > configure but before building any project using the make command. > > Does this make it any clearer? Basically I wish to access the > environment variables you create (if it works that way) after the > configure command. The configure command doesn't create environment variables it sets make variables (into spec.gmk and hotspot-spec.gmk, and the path you list consists of pieces that come from many different places: > $OPENJDK_RELEASE_NAME Simplest thing is for you to define this by naming the configuration or running configure from that directory. > $OS_PLATFORM_COMPILER_FOLDER You would have to create this the same was as hotspot by building it up from OS, architecture and whether doing client/server/minimal VM build. This is non-trivial in general but maybe easier depending on your platform. The VM part is hard because depending on the make target invoked, or the value of JVM_VARIANTS, different VMs will be built. But as you will have used --with-jvm-variants as a configure arg you should know what to look for: client=compiler1, server=compiler2 etc > $BUILD_TYPE Partially inferrable from --with-debug-level=XXX: - release -> product - debug -> debug - fastdebug -> fastdebug but I don't think the other variants are exposed at the configure level. HTH David > Thanks. > > Cheers, > Mani > > On Fri, Feb 15, 2013 at 7:06 AM, David Holmes > wrote: > > On 15/02/2013 10:55 AM, Mani Sarkar wrote: > > Hi all again, > > I did some searching in the OpenJDK folders and found the below > notations: > > *$(CONF_NAME)* in the below line in one of the make files: > > @$(PRINTF) "Building $(PRODUCT_NAME) for target '$(call > GetRealTarget)' in > configuration '$(CONF_NAME)'\n\n" > > > You can name a configuration anything you want. There is a configure > option for it --with-conf-name > > And the below from another one: > *$(OSNAME)_$(BUILDARCH)___compiler2* > *$(OUTPUTDIR)/$(VM_PLATFORM)___compiler2* > > > How could we parse these outside the make file to get some value > that I > could use (provided we have run configure). Do these flags > expect other > flags to be set before they can be parsed? > > > I'm not quite sure what you are asking. > > David > > Thanks. > > Cheers, > mani > > On Thu, Feb 14, 2013 at 7:09 PM, Mani Sarkar > > wrote: > > Hi, > > I had asked a query [1] long ago in line with the different > builds types > when build the OpenJDK project or sub-projects. I have > another query > related to it - i.e. is there a way to determine what type > of build you are > currently configured for? Is there an OS environment > variable that contains > one of the following after we run configure: > > debug > fastdebug > generated > jvmg > optimized > product > profiles > > > My other query with regards to the folder '* > linux-x86_64-normal-server-__release*/' under the main > /build folder. The > > naming is OS, CPU and other factors dependant, is there a > way to determine > through an OS environment variable or through calling a > script what name > the folder would get when a build was successful? > > Any suggestions leading to answers to the above would be highly > appreciated. > > Thanks. > > Cheers > mani > [1] > http://www.mail-archive.com/__build-dev at openjdk.java.net/__msg07325.html > > -- > *Twitter:* @theNeomatrix369 > *Blog:* http://neomatrix369.wordpress.__com > > *JUG activity:* LJC Advocate > *Meet-a-Project:* https://github.com/__MutabilityDetector > > *Come to Devoxx UK 2013:* > http://www.devoxx.com/display/__UK13/Home > > > *Don't chase success, rather aim for "Excellence", and > success will come > chasing after you!* > > > > > > > > -- > *Twitter:* @theNeomatrix369 > *Blog:* http://neomatrix369.wordpress.com > *JUG activity:* LJC Advocate > *Meet-a-Project:* https://github.com/MutabilityDetector > *Come to Devoxx UK 2013:* http://www.devoxx.com/display/UK13/Home > */Don't chase success, rather aim for "Excellence", and success will > come chasing after you!/* From dmitry.samersoff at oracle.com Fri Feb 15 10:58:00 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 15 Feb 2013 14:58:00 +0400 Subject: OpenJDK rebuilding on windows takes a long time In-Reply-To: <511D97AD.4090309@oracle.com> References: <5114ED06.1040802@oracle.com> <51150FB3.7@oracle.com> <5118D476.6030203@oracle.com> <5118DE08.4080709@oracle.com> <511B7B50.3070402@oracle.com> <511CBB69.3090605@oracle.com> <511D97AD.4090309@oracle.com> Message-ID: <511E14B8.7020401@oracle.com> Ioi, Approx the same task on 8GB CoreI5 laptop (Gentoo Linux, XFS, SSD drive), takes about a minute: real 1m14.854s user 1m43.881s sys 0m6.344s So the problem may reside in IO speed of the virtual environment. -Dmitry On 2013-02-15 06:04, Ioi Lam wrote: > On 02/14/2013 02:24 AM, Alexander Scherbatiy wrote: >> On 2/13/2013 8:45 PM, Kelly O'Hair wrote: >>> You are pointing at the fastdebug jdk as your boot jdk, why? >>> >>> The official boot jdk for jdk8 is jdk7u7 we cannot guarantee anything >>> else will work, although it should, >>> when tracking down issues like this, you need to narrow down all the >>> possible differences. >>> >>> I have no idea at this time what the 'sync state' is with the awt >>> team forest. >>> My recommendation would be to clone the official jdk8/jdk8 forest, >>> which can be assumed to work since >>> RE should have built it, or any integrator pushing changes into it >>> should have built it. >>> Create 2 forests of so you can do separate experiments on each. >> The question was about time rebuilding JDK after a small change. >> >> What time does it take to rebuild the official jdk8/jdk8 forest >> with default options after small change in the java file like >> javax.swing.JFrame ? > > > FYI: > > I am running on Oracle Enterprise Linux 5.0 with official jdk1.7.0_09 as > my boot jdk. It's a virtual host with > Xeon E5-2690 (only 2 cores allocated) and 12 GB RAM. JDK sources is put > on local disk. A one-liner change in URLClassLoader.java takes about 4 > minutes. I didn't specify sjavac when running configure. > > ----- Build times ------- > Start 2013-02-14 12:12:14 > End 2013-02-14 12:16:13 > 00:00:00 corba > 00:00:01 demos > 00:00:12 hotspot > 00:00:23 images > 00:00:00 jaxp > 00:00:00 jaxws > 00:03:23 jdk > 00:00:00 langtools > 00:03:59 TOTAL > ------------------------- > Finished building Java(TM) for target 'images' > > Is there an option in the makefiles to compile ONLY the .java file > that's changed (assuming I know the changes won't affect other classes)? > > - Ioi > >> Is sjavac are enabled by default now in the official jdk8/jdk8? >> If no, what time does it take to rebuild the JDK with the >> --enable-sjavac option? >> >> Thanks, >> Alexandr. >> >>> Then do the build from the root with a 7u7 jdk in your PATH (no need >>> for the --with-boot-jdk option). >>> Do a build without --enable-sjavac on one forest, then with it on the >>> other. >>> >>> -kto >>> >>> On Feb 13, 2013, at 3:38 AM, Alexander Scherbatiy wrote: >>> >>>> On 2/11/2013 4:03 PM, Erik Joelsson wrote: >>>>> The long term solution to this is sjavac. I do not know if it has >>>>> made it into that forest yet. You can try by adding --enable-sjavac >>>>> to configure and do a clean build. If the build works, you have it, >>>>> and incremental builds will be much faster. >>>> I tried to use the --enable-sjavac option and JDK 7 and 8 as a >>>> boot JDK. >>>> --with-boot-jdk=/cygdrive/c/Sun/Tools/JDK/jdk7/7u14/b10/jdk1.7.0_14/fastdebug >>>> --with-target-bits=32 --enable-sjavac >>>> gives compilation error >>>> >>>> --with-boot-jdk=/cygdrive/c/Sun/Tools/JDK/jdk8/b75/jdk1.8.0/fastdebug --with-target-bits=32 >>>> --enable-sjavac >>>> gives "OutOfMemoryError: Java heap space" error. >>>> >>>> The log files are attached. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> /Erik >>>>> >>>>> On 2013-02-11 12:22, Alexander Scherbatiy wrote: >>>>>> On 2/8/2013 6:46 PM, Erik Joelsson wrote: >>>>>>> Ccache is not supported on windows since it doesn't work with >>>>>>> visual studio AFAIK. >>>>>>> >>>>>>> What kind of change did you do? Was it in native code or java and >>>>>>> in which repository? >>>>>> I use the http://hg.openjdk.java.net/jdk8/awt repository, edit >>>>>> java code and build the jdk. >>>>>> To reproduce the issue: >>>>>> - open the javax.swing.JFrame class and add a comment line: >>>>>> // a comment >>>>>> - build jdk >>>>>> >>>>>> ----- Build times ------- >>>>>> Start 2013-02-11 15:09:55 >>>>>> End 2013-02-11 15:17:08 >>>>>> 00:00:03 corba >>>>>> 00:00:02 hotspot >>>>>> 00:00:01 jaxp >>>>>> 00:00:03 jaxws >>>>>> 00:06:54 jdk >>>>>> 00:00:02 langtools >>>>>> 00:07:13 TOTAL >>>>>> ------------------------- >>>>>> >>>>>> My environment: >>>>>> OS: Windows 7 Professional, x64 >>>>>> Processor - Intel Core i7 >>>>>> Memory - 8 GB >>>>>> >>>>>> The log file is attached. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> /Erik >>>>>>> >>>> >>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From erik.joelsson at oracle.com Fri Feb 15 12:06:14 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Feb 2013 13:06:14 +0100 Subject: Review Request: 8004352: build-infra: Limit JOBS on large machines Message-ID: <511E24B6.2040309@oracle.com> The current default for number of parallel build jobs is just equal to the number of cores in the system. While this works well on many machines, there have been several reports of this not working. I have been trying to come up with a better scheme for the default and the following is something that I think will do. It has been active in the build-infra forest for a while now. The complaints that were raised were usually concerning one of the following: * A big machine with very many cpus didn't scale well when using all of them, so there is no point in trying to, it just made the build less stable. Suggestion, introduce a hard cap. * A machine with lots of cpus but not as much memory would run out of memory. Suggestion, limit number of jobs on memory as well as cpus. * The build eats up all my resources, leaving my browser unusable. Suggestion, don't use everything unless asked for. So this is what I ended up with: 1. Take the min of num_cores and memory_size/1000 2. Cap at 16 3. If more than 4 cores, shave it to 90% rounded down to leave some room. The user can still override this in two ways. Either by using any of the configure arguments: --with-num-cores number of cores in the build system, e.g. --with-num-cores=8 [probed] --with-memory-size memory (in MB) available in the build system, e.g. --with-memory-size=1024 [probed] --with-jobs number of parallel jobs to let make run [calculated based on cores and memory] Or by setting JOBS= on the make command line. Also not that this change will set the CONCURRENT_BUILD_JOBS for hotspot to the value of JOBS so that it too will be overridden by the above. http://cr.openjdk.java.net/~erikj/8004352/webrev.root.01/ /Erik From erik.joelsson at oracle.com Fri Feb 15 13:02:45 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Feb 2013 14:02:45 +0100 Subject: Review Request: 8008294: build-infra: Build-infra closed fails on solaris 11.1 Message-ID: <511E31F5.8010805@oracle.com> Small patch to enable building with a newer compiler on Solaris when closed is available. The open part of this was fixed previously in 8002365. The patch adds '-lc' to the link lines for solaris. http://cr.openjdk.java.net/~erikj/8008294/webrev.jdk.01/ /Erik From erik.joelsson at oracle.com Fri Feb 15 13:23:11 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Feb 2013 14:23:11 +0100 Subject: Review Request: 8008295: build-infra: Cleanup in Import.gmk Message-ID: <511E36BF.7030104@oracle.com> Cleaning up in jdk/makefiles/Import.gmk. Removing two copies of the install-file macro which is already defined in common/makefiles/MakeBase.gmk. http://cr.openjdk.java.net/~erikj/8008295/webrev.jdk.01/ /Erik From david.holmes at oracle.com Fri Feb 15 13:32:57 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Feb 2013 23:32:57 +1000 Subject: Review Request: 8008294: build-infra: Build-infra closed fails on solaris 11.1 In-Reply-To: <511E31F5.8010805@oracle.com> References: <511E31F5.8010805@oracle.com> Message-ID: <511E3909.7000200@oracle.com> Erik, On 15/02/2013 11:02 PM, Erik Joelsson wrote: > Small patch to enable building with a newer compiler on Solaris when > closed is available. The open part of this was fixed previously in > 8002365. The patch adds '-lc' to the link lines for solaris. I don't understand your references to open and closed here. David > http://cr.openjdk.java.net/~erikj/8008294/webrev.jdk.01/ > > /Erik From oehrstroem at gmail.com Fri Feb 15 13:55:50 2013 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Fri, 15 Feb 2013 14:55:50 +0100 Subject: Review Request: 8008295: build-infra: Cleanup in Import.gmk In-Reply-To: <511E36BF.7030104@oracle.com> References: <511E36BF.7030104@oracle.com> Message-ID: ok 2013/2/15 Erik Joelsson : > Cleaning up in jdk/makefiles/Import.gmk. Removing two copies of the > install-file macro which is already defined in > common/makefiles/MakeBase.gmk. > > http://cr.openjdk.java.net/~erikj/8008295/webrev.jdk.01/ > > /Erik From erik.joelsson at oracle.com Fri Feb 15 14:11:57 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Feb 2013 15:11:57 +0100 Subject: Review Request: 8008294: build-infra: Build-infra closed fails on solaris 11.1 In-Reply-To: <511E3909.7000200@oracle.com> References: <511E31F5.8010805@oracle.com> <511E3909.7000200@oracle.com> Message-ID: <511E422D.9080805@oracle.com> On 2013-02-15 14:32, David Holmes wrote: > Erik, > > On 15/02/2013 11:02 PM, Erik Joelsson wrote: >> Small patch to enable building with a newer compiler on Solaris when >> closed is available. The open part of this was fixed previously in >> 8002365. The patch adds '-lc' to the link lines for solaris. > > I don't understand your references to open and closed here. > > David > I guess I wrote that too fast. In the bug referenced above, similar -lc parameters were added to most (if not all) library link lines that are part of openjdk. This patch complements those changes by adding -lc to the libraries which still have their make logic in the open but source in closed. /Erik >> http://cr.openjdk.java.net/~erikj/8008294/webrev.jdk.01/ >> >> /Erik From david.holmes at oracle.com Fri Feb 15 14:19:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Feb 2013 00:19:20 +1000 Subject: Review Request: 8008294: build-infra: Build-infra closed fails on solaris 11.1 In-Reply-To: <511E422D.9080805@oracle.com> References: <511E31F5.8010805@oracle.com> <511E3909.7000200@oracle.com> <511E422D.9080805@oracle.com> Message-ID: <511E43E8.1000403@oracle.com> On 16/02/2013 12:11 AM, Erik Joelsson wrote: > On 2013-02-15 14:32, David Holmes wrote: >> Erik, >> >> On 15/02/2013 11:02 PM, Erik Joelsson wrote: >>> Small patch to enable building with a newer compiler on Solaris when >>> closed is available. The open part of this was fixed previously in >>> 8002365. The patch adds '-lc' to the link lines for solaris. >> >> I don't understand your references to open and closed here. >> >> David >> > I guess I wrote that too fast. In the bug referenced above, similar -lc > parameters were added to most (if not all) library link lines that are > part of openjdk. This patch complements those changes by adding -lc to > the libraries which still have their make logic in the open but source > in closed. Got it - thanks. Looks okay. David > /Erik > >>> http://cr.openjdk.java.net/~erikj/8008294/webrev.jdk.01/ >>> >>> /Erik From peter.brunet at oracle.com Fri Feb 15 15:10:40 2013 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 15 Feb 2013 09:10:40 -0600 Subject: recent problems with JFX ant script In-Reply-To: <511E0D5D.4060103@oracle.com> References: <511D49D0.9010205@oracle.com> <511E0D5D.4060103@oracle.com> Message-ID: <511E4FF0.8040902@oracle.com> Another one I've see is: ... run-vs-property-generator: [echo] Using C:\Users\Pete\JavaFX\controls\jfx\build-src\genVSproperties.bat to get VS properties. compile-native: [exec] make: uname: Command not found [exec] make: mkdir: Command not found [exec] make: *** [.build-pre] Error 127 BUILD FAILED C:\Users\Pete\JavaFX\controls\jfx\build-src\build-components.xml:324: The following error occurred while executing this line: ... This was after a reboot, start cygwin, run vsvars.sh, unset tmp, unset temp, ant clean, ant -Dhudson.jfx.job.name=8.0-controls-scrum sdk-no-docs I haven't figured out how to workaround that yet. (I forgot to turn off Norton 360 auto-protect so maybe that's it - or maybe not - I haven't had problems with JFX builds until this week.) Pete On 2/15/13 4:26 AM, Anthony Petrov wrote: > It's a known issue: > > http://javafx-jira.kenai.com/browse/RT-27210 > > -- > best regards, > Anthony > > On 2/15/2013 0:32, Pete Brunet wrote: >> I ran into two new problems building JFX on Win 7 this week: >> >> 1) I had to unset lowercase tmp and temp. Apparently there is a new >> problem with having duplicates, TMP/tmp and TEMP/temp. This may be >> related to http://www.cmake.org/Bug/print_bug_page.php?bug_id=13131 >> >> The failure appeared as: >> >> launcher-win: >> [echo] STARTING: C:\Program Files (x86)\Microsoft Visual Studio >> 10.0\Common7\IDE\devenv.com native/windows >> [echo] C:\Program Files (x86)\Microsoft Visual Studio >> 10.0\Common7\IDE\devenv.com /build Release|Win32 IconSwap.vcxproj >> [exec] >> [exec] Microsoft (R) Visual Studio Version 10.0.30319.1. >> [exec] Copyright (coffee) Microsoft Corp. All rights reserved. >> [exec] 1>------ Build started: Project: IconSwap, Configuration: >> Release Win32 ------ >> [exec] 1>C:\Program Files >> (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(147,5): >> >> error MSB6001: Invalid command line switch for "CL.exe". Item has >> already been added. Key in dictionary: 'tmp' Key being added: 'TMP' >> [exec] ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 >> skipped === >> >> 2) DEVENVDIR somehow gets unset. I had to rerun vsvars.sh to fix it. >> This failure appeared as: >> >> needs-devenv: >> [echo] Using >> C:\Users\Pete\JavaFX\controls-RT-26343\jfx\rt-closed\glass\glass-mat-lib-windows\${windows.vs.DEVENVCMD}. >> >> >> BUILD FAILED >> >> Both of these showed up when building on Windows 7 which I haven't done >> in a while. I was just rerunning the ant script over and over after >> source code changes. I use ant -Dhudson.jfx.job.name=8.0-controls-scrum >> sdk-no-docs >> >> Since the problem is intermittent I supposed these could be related to >> the combination of cygwin/Norton360. I'll disable Norton auto-protect >> for a while to see if that helps, but wanted to let others know of this >> in case it's helpful. >> >> Pete From alexandr.scherbatiy at oracle.com Fri Feb 15 15:18:02 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 15 Feb 2013 19:18:02 +0400 Subject: OpenJDK rebuilding on windows takes a long time In-Reply-To: References: <5114ED06.1040802@oracle.com> <51150FB3.7@oracle.com> <5118D476.6030203@oracle.com> <5118DE08.4080709@oracle.com> <511B7B50.3070402@oracle.com> Message-ID: <511E51AA.6000109@oracle.com> On 2/13/2013 8:45 PM, Kelly O'Hair wrote: > You are pointing at the fastdebug jdk as your boot jdk, why? > > The official boot jdk for jdk8 is jdk7u7 we cannot guarantee anything else will work, although it should, > when tracking down issues like this, you need to narrow down all the possible differences. > > I have no idea at this time what the 'sync state' is with the awt team forest. > My recommendation would be to clone the official jdk8/jdk8 forest, which can be assumed to work since > RE should have built it, or any integrator pushing changes into it should have built it. > Create 2 forests of so you can do separate experiments on each. > > Then do the build from the root with a 7u7 jdk in your PATH (no need for the --with-boot-jdk option). > Do a build without --enable-sjavac on one forest, then with it on the other. I made the proposed experiment. My goal is to build debug version of JDK that does not take a long time to rebuild. I put 1.7.0_07-b32 to PATH variable so ------------------------------------------------------------------- $ java -version java version "1.7.0_07" Java(TM) SE Runtime Environment (build 1.7.0_07-b32) Java HotSpot(TM) Client VM (build 23.3-b01, mixed mode) ------------------------------------------------------------------ I used http://hg.openjdk.java.net/jdk8/jdk8 repository. Each time I used the clean repository. 1) Build only debug version configure-arguments: --with-target-bits=32 --enable-debug ----- Build times ------- Start 2013-02-15 16:22:41 End 2013-02-15 16:40:01 00:00:45 corba 00:04:54 hotspot 00:00:38 jaxp 00:00:56 jaxws 00:09:18 jdk 00:00:41 langtools 00:17:20 TOTAL ------------------------- Build is successful. 2a) Build debug version with sjava (the same JDK in PATH, the same repository) configure-arguments: --with-target-bits=32 --enable-debug --enable-sjavac 100 errors 3 warnings make[1]: *** [/cygdrive/c/Sun/OpenJDK/utils/config/jdk8-sjavac/build/windows-x86-normal-server-fastdebug/jaxws/jaxws_classes/javac_state] Error 127 make[1]: *** Waiting for unfinished jobs.... make: *** [jaxws-only] Error 2 See the attached out.txt and out.txt files in the attached zip. 2b) Build debug version with sjava (the same JDK in PATH, the same repository) configure-arguments: --with-target-bits=32 --enable-debug --enable-sjavac with the suggested patch that checks "os.name" variable: ----------------------------------------------------------- diff --git a/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java b/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java --- a/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java +++ b/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java @@ -255,7 +255,7 @@ } // Load visible sources Set visibleSources = new HashSet(); - boolean fix_drive_letter_case = System.getProperty("os.name").toLowerCase().equals("windows"); + boolean fix_drive_letter_case = System.getProperty("os.name").toLowerCase().startsWith("windows"); for (;;) { String l = in.readLine(); if (l == null) ----------------------------------------------------------- Compilation fails with error: ----------------------------------------------------------- The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError: Java heap space ----------------------------------------------------------- See the attached out_patch.txt and err_patch.txt files in the attached zip. Could you check this scenario (--with-target-bits=32 --enable-debug --enable-sjavac) on your side? Thanks, Alexandr. > -kto From volker.simonis at gmail.com Fri Feb 15 15:21:17 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 15 Feb 2013 16:21:17 +0100 Subject: Review Request: 8004352: build-infra: Limit JOBS on large machines In-Reply-To: <511E24B6.2040309@oracle.com> References: <511E24B6.2040309@oracle.com> Message-ID: Hi Erik, I really like these changes! Thank you for addressing these problems. Volker On Fri, Feb 15, 2013 at 1:06 PM, Erik Joelsson wrote: > The current default for number of parallel build jobs is just equal to the > number of cores in the system. While this works well on many machines, there > have been several reports of this not working. I have been trying to come up > with a better scheme for the default and the following is something that I > think will do. It has been active in the build-infra forest for a while now. > > The complaints that were raised were usually concerning one of the > following: > > * A big machine with very many cpus didn't scale well when using all of > them, so there is no point in trying to, it just made the build less stable. > Suggestion, introduce a hard cap. > * A machine with lots of cpus but not as much memory would run out of > memory. Suggestion, limit number of jobs on memory as well as cpus. > * The build eats up all my resources, leaving my browser unusable. > Suggestion, don't use everything unless asked for. > > So this is what I ended up with: > 1. Take the min of num_cores and memory_size/1000 > 2. Cap at 16 > 3. If more than 4 cores, shave it to 90% rounded down to leave some room. > > The user can still override this in two ways. Either by using any of the > configure arguments: > > --with-num-cores number of cores in the build system, e.g. > --with-num-cores=8 [probed] > --with-memory-size memory (in MB) available in the build system, e.g. > --with-memory-size=1024 [probed] > --with-jobs number of parallel jobs to let make run > [calculated > based on cores and memory] > > Or by setting JOBS= on the make command line. > > Also not that this change will set the CONCURRENT_BUILD_JOBS for hotspot to > the value of JOBS so that it too will be overridden by the above. > > http://cr.openjdk.java.net/~erikj/8004352/webrev.root.01/ > > /Erik From peter.brunet at oracle.com Fri Feb 15 16:29:56 2013 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 15 Feb 2013 10:29:56 -0600 Subject: recent problems with JFX ant script In-Reply-To: <511E4FF0.8040902@oracle.com> References: <511D49D0.9010205@oracle.com> <511E0D5D.4060103@oracle.com> <511E4FF0.8040902@oracle.com> Message-ID: <511E6284.4000701@oracle.com> I'm seeing this when using -Dbuild.debug (and Norton 360 auto-protect off). I may have not seen it a non-debug build. On 2/15/13 9:10 AM, Pete Brunet wrote: > Another one I've see is: > > ... > run-vs-property-generator: > [echo] Using > C:\Users\Pete\JavaFX\controls\jfx\build-src\genVSproperties.bat to get > VS properties. > > compile-native: > [exec] make: uname: Command not found > [exec] make: mkdir: Command not found > [exec] make: *** [.build-pre] Error 127 > > BUILD FAILED > C:\Users\Pete\JavaFX\controls\jfx\build-src\build-components.xml:324: > The following error occurred while executing this line: > ... > > This was after a reboot, start cygwin, run vsvars.sh, unset tmp, unset > temp, ant clean, ant -Dhudson.jfx.job.name=8.0-controls-scrum sdk-no-docs > > I haven't figured out how to workaround that yet. (I forgot to turn off > Norton 360 auto-protect so maybe that's it - or maybe not - I haven't > had problems with JFX builds until this week.) > > Pete > > On 2/15/13 4:26 AM, Anthony Petrov wrote: >> It's a known issue: >> >> http://javafx-jira.kenai.com/browse/RT-27210 >> >> -- >> best regards, >> Anthony >> >> On 2/15/2013 0:32, Pete Brunet wrote: >>> I ran into two new problems building JFX on Win 7 this week: >>> >>> 1) I had to unset lowercase tmp and temp. Apparently there is a new >>> problem with having duplicates, TMP/tmp and TEMP/temp. This may be >>> related to http://www.cmake.org/Bug/print_bug_page.php?bug_id=13131 >>> >>> The failure appeared as: >>> >>> launcher-win: >>> [echo] STARTING: C:\Program Files (x86)\Microsoft Visual Studio >>> 10.0\Common7\IDE\devenv.com native/windows >>> [echo] C:\Program Files (x86)\Microsoft Visual Studio >>> 10.0\Common7\IDE\devenv.com /build Release|Win32 IconSwap.vcxproj >>> [exec] >>> [exec] Microsoft (R) Visual Studio Version 10.0.30319.1. >>> [exec] Copyright (coffee) Microsoft Corp. All rights reserved. >>> [exec] 1>------ Build started: Project: IconSwap, Configuration: >>> Release Win32 ------ >>> [exec] 1>C:\Program Files >>> (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(147,5): >>> >>> error MSB6001: Invalid command line switch for "CL.exe". Item has >>> already been added. Key in dictionary: 'tmp' Key being added: 'TMP' >>> [exec] ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 >>> skipped === >>> >>> 2) DEVENVDIR somehow gets unset. I had to rerun vsvars.sh to fix it. >>> This failure appeared as: >>> >>> needs-devenv: >>> [echo] Using >>> C:\Users\Pete\JavaFX\controls-RT-26343\jfx\rt-closed\glass\glass-mat-lib-windows\${windows.vs.DEVENVCMD}. >>> >>> >>> BUILD FAILED >>> >>> Both of these showed up when building on Windows 7 which I haven't done >>> in a while. I was just rerunning the ant script over and over after >>> source code changes. I use ant -Dhudson.jfx.job.name=8.0-controls-scrum >>> sdk-no-docs >>> >>> Since the problem is intermittent I supposed these could be related to >>> the combination of cygwin/Norton360. I'll disable Norton auto-protect >>> for a while to see if that helps, but wanted to let others know of this >>> in case it's helpful. >>> >>> Pete From mike.duigou at oracle.com Fri Feb 15 17:12:25 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 15 Feb 2013 09:12:25 -0800 Subject: Review Request: 8004352: build-infra: Limit JOBS on large machines In-Reply-To: <511E24B6.2040309@oracle.com> References: <511E24B6.2040309@oracle.com> Message-ID: <97C179D7-3CD4-4213-AA39-A61E735D7136@oracle.com> A couple of comments; - Can you reverse steps #2 and #3? Having the hard cap last makes more sense. - In JDK-8007327 I requested some memory size definitions such as MEMORY_SIZE_NORMAL_HEAP for sizing of JVM heaps. The explicit "1000" should probably be replaced with the MEMORY_SIZE_NORMAL_HEAP constant. Elsewhere the value is "1100". - The CONCURRENT_BUILD_JOBS is no longer JOBS * 2. Do we think that's right? Mike On Feb 15 2013, at 04:06 , Erik Joelsson wrote: > The current default for number of parallel build jobs is just equal to the number of cores in the system. While this works well on many machines, there have been several reports of this not working. I have been trying to come up with a better scheme for the default and the following is something that I think will do. It has been active in the build-infra forest for a while now. > > The complaints that were raised were usually concerning one of the following: > > * A big machine with very many cpus didn't scale well when using all of them, so there is no point in trying to, it just made the build less stable. Suggestion, introduce a hard cap. > * A machine with lots of cpus but not as much memory would run out of memory. Suggestion, limit number of jobs on memory as well as cpus. > * The build eats up all my resources, leaving my browser unusable. Suggestion, don't use everything unless asked for. > > So this is what I ended up with: > 1. Take the min of num_cores and memory_size/1000 > 2. Cap at 16 > 3. If more than 4 cores, shave it to 90% rounded down to leave some room. > > The user can still override this in two ways. Either by using any of the configure arguments: > > --with-num-cores number of cores in the build system, e.g. > --with-num-cores=8 [probed] > --with-memory-size memory (in MB) available in the build system, e.g. > --with-memory-size=1024 [probed] > --with-jobs number of parallel jobs to let make run [calculated > based on cores and memory] > > Or by setting JOBS= on the make command line. > > Also not that this change will set the CONCURRENT_BUILD_JOBS for hotspot to the value of JOBS so that it too will be overridden by the above. > > http://cr.openjdk.java.net/~erikj/8004352/webrev.root.01/ > > /Erik From david.katleman at oracle.com Fri Feb 15 19:41:41 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 15 Feb 2013 19:41:41 +0000 Subject: hg: jdk8/build: 7 new changesets Message-ID: <20130215194142.28A9F47B02@hg.openjdk.java.net> Changeset: 45dcccc6d221 Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/45dcccc6d221 Added tag jdk8-b77 for changeset 3933eebc659d ! .hgtags Changeset: 8dd61906da5f Author: chegar Date: 2013-02-06 11:36 +0000 URL: http://hg.openjdk.java.net/jdk8/build/rev/8dd61906da5f 8007625: race with nested repos in /common/bin/hgforest.sh Reviewed-by: dholmes, ohair, ohrstrom ! common/bin/hgforest.sh ! get_source.sh Changeset: 168dd033604a Author: mduigou Date: 2013-02-06 11:09 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/168dd033604a 8004726: Link bug ids to jbs rather than monaco. Reviewed-by: ohair, chegar, katleman ! make/scripts/webrev.ksh Changeset: 7817368287cd Author: mduigou Date: 2013-02-06 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/7817368287cd 8006595: Use jdk/test/Makefile targets in preference to local definitions Reviewed-by: alanb ! common/makefiles/Main.gmk ! test/Makefile Changeset: fdb1e09519ed Author: sherman Date: 2013-02-12 09:27 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/fdb1e09519ed 8007392: JSR 310: DateTime API Updates Summary: Integration of JSR310 Date/Time API for M7 Reviewed-by: darcy, alanb, naoto Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com, patrick.zhang at oracle.com ! common/makefiles/javadoc/CORE_PKGS.gmk Changeset: 76808fb4194a Author: lana Date: 2013-02-13 11:21 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/76808fb4194a Merge ! common/makefiles/Main.gmk Changeset: bbb7548d45c7 Author: lana Date: 2013-02-14 22:11 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/bbb7548d45c7 Merge From david.katleman at oracle.com Fri Feb 15 19:41:45 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 15 Feb 2013 19:41:45 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b77 for changeset 35684a40c584 Message-ID: <20130215194146.D511947B03@hg.openjdk.java.net> Changeset: 27d6368ae8ba Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/27d6368ae8ba Added tag jdk8-b77 for changeset 35684a40c584 ! .hgtags From david.katleman at oracle.com Fri Feb 15 19:43:30 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 15 Feb 2013 19:43:30 +0000 Subject: hg: jdk8/build/hotspot: Added tag jdk8-b77 for changeset cdb46031e718 Message-ID: <20130215194334.5AF4747B04@hg.openjdk.java.net> Changeset: 1f84c84f8e1a Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1f84c84f8e1a Added tag jdk8-b77 for changeset cdb46031e718 ! .hgtags From david.katleman at oracle.com Fri Feb 15 19:45:32 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 15 Feb 2013 19:45:32 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b77 for changeset 573e789c187a Message-ID: <20130215194536.30B2847B05@hg.openjdk.java.net> Changeset: 00958c5a7070 Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/00958c5a7070 Added tag jdk8-b77 for changeset 573e789c187a ! .hgtags From david.katleman at oracle.com Fri Feb 15 19:45:41 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 15 Feb 2013 19:45:41 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b77 for changeset 64dfba1bad16 Message-ID: <20130215194544.5B7CA47B06@hg.openjdk.java.net> Changeset: 391de4c992d1 Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/391de4c992d1 Added tag jdk8-b77 for changeset 64dfba1bad16 ! .hgtags From david.katleman at oracle.com Fri Feb 15 19:46:49 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 15 Feb 2013 19:46:49 +0000 Subject: hg: jdk8/build/jdk: 48 new changesets Message-ID: <20130215195612.9FF1747B07@hg.openjdk.java.net> Changeset: c1304eb051f6 Author: katleman Date: 2013-02-14 11:44 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c1304eb051f6 Added tag jdk8-b77 for changeset b2fc8e31cecc ! .hgtags Changeset: 37719b174e87 Author: jgodinez Date: 2013-02-06 14:45 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/37719b174e87 8005194: [parfait] #353 sun/awt/image/jpeg/imageioJPEG.c Memory leak of pointer 'scale' allocated with calloc() Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: ad49012d10a1 Author: jgodinez Date: 2013-02-08 11:25 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ad49012d10a1 8005129: [parfait] #1122 - #1130 native/sun/awt/medialib/mlib_Image*.c Memory leak of pointer 'k' allocated with mlib_malloc Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/awt/medialib/mlib_ImageConv.h ! src/share/native/sun/awt/medialib/mlib_ImageConvMxN_ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_16nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_32nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16nw.c ! src/share/native/sun/awt/medialib/mlib_ImageCreate.c ! src/share/native/sun/awt/medialib/mlib_c_ImageConv.h Changeset: 1ea9feb6d8c5 Author: jgodinez Date: 2013-02-08 11:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1ea9feb6d8c5 8005261: [parfait] #415 sun/java2d/opengl/GLXSurfaceData.c Memory leak of pointer 'glxsdo' allocated with malloc Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c Changeset: 5f0217537435 Author: prr Date: 2013-02-12 09:58 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5f0217537435 8007748: MacOSX build error : cast of type 'SEL' to 'uintptr_t' (aka 'unsigned long') is deprecated; use sel_getName instead Reviewed-by: anthony ! src/macosx/native/jobjc/src/core/native/SEL.m Changeset: 1b47e2dfa89a Author: lana Date: 2013-02-13 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1b47e2dfa89a Merge - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java - test/java/net/URL/abnormal_http_urls - test/java/net/URL/ftp_urls - test/java/net/URL/jar_urls - test/java/net/URL/normal_http_urls - test/java/net/URL/runconstructor.sh - test/java/net/URL/share_file_urls - test/java/net/URL/win32_file_urls - test/sun/net/www/EncDec.doc - test/sun/net/www/MarkResetTest.java - test/sun/net/www/MarkResetTest.sh - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java Changeset: 6df3acd02449 Author: prr Date: 2013-02-13 15:06 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6df3acd02449 8008017: The fix for 8005129 does not build on Windows Reviewed-by: prr, jgodinez Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/awt/medialib/mlib_ImageConv_16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_16nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16nw.c Changeset: ac89a5d71466 Author: alexsch Date: 2013-02-06 18:25 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ac89a5d71466 8000326: Focus unable to traverse in the menubar Reviewed-by: alexsch, malenkov ! src/share/classes/javax/swing/JMenuBar.java Changeset: 6e17465f4a1a Author: mcherkas Date: 2013-02-08 22:08 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6e17465f4a1a 8005932: Java 7 on mac os x only provides text clipboard formats Reviewed-by: alexp, denis ! src/macosx/lib/flavormap.properties + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/AbsoluteComponentCenterCalculator.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/DataFlavorSearcher.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/InterprocessMessages.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MyTransferable.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/NextFramePositionCalculator.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/SourcePanel.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/TargetPanel.java Changeset: 5406c4e381e2 Author: kshefov Date: 2013-02-13 18:01 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5406c4e381e2 7161759: TEST_BUG: java/awt/Frame/WindowDragTest/WindowDragTest.java fails to compile, should be modified Summary: Added @build Util jtreg tag Reviewed-by: serb, alexsch Contributed-by: Vera Akulova ! test/java/awt/Frame/WindowDragTest/WindowDragTest.java Changeset: dd6cf41a6953 Author: kshefov Date: 2013-02-13 19:06 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/dd6cf41a6953 7132383: [macosx] bug6596966.java should be adapted for Mac Reviewed-by: serb, alexsch Contributed-by: Vera Akulova ! test/javax/swing/JLabel/6596966/bug6596966.java ! test/javax/swing/regtesthelpers/Util.java Changeset: caec64340f42 Author: vkarnauk Date: 2013-02-13 19:23 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/caec64340f42 4199622: RFE: JComboBox shouldn't sending ActionEvents for keyboard navigation Reviewed-by: alexp, alexsch ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java + test/javax/swing/JComboBox/4199622/bug4199622.java Changeset: 4d9691e95e05 Author: pchelko Date: 2013-02-13 15:27 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4d9691e95e05 7079260: InputContext leaks memory Summary: Replaced strong refs with weak refs Reviewed-by: art, serb ! src/share/classes/sun/awt/im/CompositionAreaHandler.java ! src/solaris/classes/sun/awt/X11InputMethod.java + test/java/awt/im/memoryleak/InputContextMemoryLeakTest.java ! test/java/awt/regtesthelpers/Util.java Changeset: c552cde0e3f9 Author: pchelko Date: 2013-02-13 15:32 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c552cde0e3f9 8005629: javac warnings compiling java.awt.EventDispatchThread and sun.awt.X11.XIconWindow Summary: Removed macosx specific workaround from shared code and made macosx use public API Reviewed-by: art, serb ! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java ! src/macosx/native/sun/awt/CPrinterJob.m ! src/share/classes/java/awt/EventDispatchThread.java ! src/solaris/classes/sun/awt/X11/XIconWindow.java Changeset: c95dc15ac183 Author: lana Date: 2013-02-13 12:38 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c95dc15ac183 Merge - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java - test/java/net/URL/abnormal_http_urls - test/java/net/URL/ftp_urls - test/java/net/URL/jar_urls - test/java/net/URL/normal_http_urls - test/java/net/URL/runconstructor.sh - test/java/net/URL/share_file_urls - test/java/net/URL/win32_file_urls - test/sun/net/www/EncDec.doc - test/sun/net/www/MarkResetTest.java - test/sun/net/www/MarkResetTest.sh - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java Changeset: c9efb349b391 Author: lana Date: 2013-02-13 17:55 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c9efb349b391 Merge - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java Changeset: 0e7d5dd84fdf Author: dsamersoff Date: 2013-02-06 16:53 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0e7d5dd84fdf 8007277: JDK-8002048 testcase fails to compile Summary: sun.* classes is not included to ct.sym file and symbol file have to be ignored Reviewed-by: alanb ! test/sun/management/jdp/JdpTest.sh Changeset: 1574fa3df1c0 Author: lancea Date: 2013-02-06 14:15 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1574fa3df1c0 8006505: additional changes for JSR 310 support Reviewed-by: naoto, ulfzibis ! src/share/classes/java/sql/JDBCType.java ! src/share/classes/java/sql/SQLInput.java ! src/share/classes/java/sql/SQLOutput.java ! src/share/classes/java/sql/Types.java Changeset: 2f1505c49e79 Author: martin Date: 2013-02-06 17:59 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2f1505c49e79 8006995: java launcher fails to open executable JAR > 2GB Summary: Use O_LARGEFILE consistently when opening jar files Reviewed-by: alanb, sherman ! src/share/bin/parse_manifest.c Changeset: 2de8c6c2d652 Author: ykantser Date: 2013-02-07 11:22 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2de8c6c2d652 8007142: Add utility classes for writing better multiprocess tests in jtreg Reviewed-by: alanb, rbackman + test/lib/testlibrary/OutputAnalyzerTest.java + test/lib/testlibrary/jdk/testlibrary/JcmdBase.java + test/lib/testlibrary/jdk/testlibrary/JdkFinder.java + test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java + test/lib/testlibrary/jdk/testlibrary/OutputBuffer.java + test/lib/testlibrary/jdk/testlibrary/ProcessTools.java + test/lib/testlibrary/jdk/testlibrary/StreamPumper.java Changeset: 79d7595abe95 Author: naoto Date: 2013-02-08 09:35 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/79d7595abe95 8007038: ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with JapaneseChrono Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java + test/java/util/Calendar/Bug8007038.java Changeset: 522fb3867a3a Author: darcy Date: 2013-02-08 16:00 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/522fb3867a3a 8005623: Retrofit FunctionalInterface annotations to core platform interfaces Reviewed-by: mduigou, chegar, alanb ! src/share/classes/java/io/Closeable.java ! src/share/classes/java/io/FileFilter.java ! src/share/classes/java/io/FilenameFilter.java ! src/share/classes/java/io/Flushable.java ! src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Comparable.java ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/lang/Readable.java ! src/share/classes/java/lang/Runnable.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/nio/file/DirectoryStream.java ! src/share/classes/java/nio/file/PathMatcher.java ! src/share/classes/java/util/Comparator.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Block.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/java/util/function/Supplier.java ! src/share/classes/java/util/function/UnaryOperator.java ! src/share/classes/java/util/logging/Filter.java ! src/share/classes/java/util/prefs/PreferenceChangeListener.java Changeset: 36d25dc2b8f0 Author: dl Date: 2013-02-09 08:35 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/36d25dc2b8f0 8005697: Add StampedLock Reviewed-by: chegar, alanb, dice, martin ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/concurrent/locks/LockSupport.java + src/share/classes/java/util/concurrent/locks/StampedLock.java + test/java/util/concurrent/locks/StampedLock/Basic.java Changeset: d14cd2272b2d Author: weijun Date: 2013-02-09 16:43 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d14cd2272b2d 8001104: Unbound SASL service: the GSSAPI/krb5 mech Reviewed-by: valeriep ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java ! src/share/classes/javax/security/auth/kerberos/KeyTab.java ! src/share/classes/sun/security/jgss/LoginConfigImpl.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/krb5/ServiceCreds.java ! src/share/classes/sun/security/jgss/krb5/SubjectComber.java ! src/share/classes/sun/security/krb5/JavaxSecurityAuthKerberosAccess.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/provider/ConfigSpiFile.java ! test/sun/security/krb5/ServiceCredsCombination.java ! test/sun/security/krb5/auto/AcceptPermissions.java + test/sun/security/krb5/auto/GSSUnbound.java ! test/sun/security/krb5/auto/OneKDC.java + test/sun/security/krb5/auto/SaslUnbound.java + test/sun/security/krb5/auto/UnboundService.java Changeset: 57cb988c811e Author: weijun Date: 2013-02-09 16:43 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/57cb988c811e 8007761: NTLM coding errors Reviewed-by: chegar ! src/share/classes/com/sun/security/ntlm/Client.java ! src/share/classes/com/sun/security/ntlm/NTLM.java Changeset: 58c95d0b6b1a Author: ksrini Date: 2013-02-10 08:07 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/58c95d0b6b1a 8007519: [unpack200] produces bad class files when producing BootstrapMethods attribute Reviewed-by: alanb ! test/ProblemList.txt Changeset: 520a3433883d Author: ksrini Date: 2013-02-10 08:49 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/520a3433883d 8007902: [unpack200] incorrect BootstrapMethods attribute Reviewed-by: jjh ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/pack200-verifier/data/golden.jar Changeset: 1df991184045 Author: dsamersoff Date: 2013-02-11 18:44 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1df991184045 8007536: Incorrect copyright header in JDP files Summary: Copyright header in JDP files missed the "classpath exception" rule. Reviewed-by: mikael ! src/share/classes/sun/management/jdp/JdpBroadcaster.java ! src/share/classes/sun/management/jdp/JdpController.java ! src/share/classes/sun/management/jdp/JdpException.java ! src/share/classes/sun/management/jdp/JdpGenericPacket.java ! src/share/classes/sun/management/jdp/JdpJmxPacket.java ! src/share/classes/sun/management/jdp/JdpPacket.java ! src/share/classes/sun/management/jdp/JdpPacketReader.java ! src/share/classes/sun/management/jdp/JdpPacketWriter.java ! src/share/classes/sun/management/jdp/package-info.java Changeset: abd530253f01 Author: dcubed Date: 2013-02-11 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/abd530253f01 8007420: add test for 6805864 to com/sun/jdi, add test for 7182152 to java/lang/instrument Reviewed-by: coleenp, sspitsyn + test/com/sun/jdi/RedefineAbstractClass.sh + test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesAgent.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesApp.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesImpl.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesImpl_1.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesIntf1.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesIntf2.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesRemote.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesTarget.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesTarget_1.java Changeset: f21a4b761424 Author: alanb Date: 2013-02-11 20:16 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f21a4b761424 8007405: Update java.lang.reflect API to replace SYNTHESIZED with MANDATED Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Modifier.java ! src/share/classes/java/lang/reflect/Parameter.java Changeset: 465cce29a9ed Author: mduigou Date: 2013-02-06 11:28 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/465cce29a9ed 8006594: Add jdk_core target to jdk/test/Makefile Reviewed-by: alanb ! make/jprt.properties ! test/Makefile ! test/ProblemList.txt Changeset: f7fb173ac833 Author: dsamersoff Date: 2013-02-12 16:02 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f7fb173ac833 8007786: JDK-8002048 testcase doesn't work on Solaris Summary: test built in into Solaris shell doesn't have -e operator Reviewed-by: sla, sspitsyn ! test/sun/management/jdp/JdpTest.sh Changeset: 7dcb74c3ffba Author: sherman Date: 2013-02-12 09:25 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7dcb74c3ffba 8007392: JSR 310: DateTime API Updates 8007520: Update date/time classes in j.util and j.sql packages 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb Summary: Integration of JSR310 Date/Time API for M7 Reviewed-by: darcy, alanb, naoto Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com, patrick.zhang at oracle.com ! make/docs/CORE_PKGS.gmk ! make/java/java/FILES_java.gmk ! make/sun/Makefile ! make/sun/javazic/Makefile + make/sun/javazic/tzdata/gmt + make/sun/javazic/tzdata/jdk11_backward ! make/sun/tzdb/Makefile ! make/tools/Makefile ! make/tools/src/build/tools/javazic/Zoneinfo.java ! make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java ! makefiles/GendataTZDB.gmk ! makefiles/GendataTimeZone.gmk ! makefiles/GenerateData.gmk ! makefiles/Tools.gmk ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/Time.java ! src/share/classes/java/sql/Timestamp.java ! src/share/classes/java/time/Clock.java ! src/share/classes/java/time/DayOfWeek.java ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/Month.java + src/share/classes/java/time/MonthDay.java + src/share/classes/java/time/OffsetDateTime.java + src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java - src/share/classes/java/time/PeriodParser.java ! src/share/classes/java/time/Ser.java + src/share/classes/java/time/Year.java + src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZoneRegion.java ! src/share/classes/java/time/ZonedDateTime.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java + src/share/classes/java/time/chrono/ChronoDateImpl.java + src/share/classes/java/time/chrono/ChronoLocalDate.java + src/share/classes/java/time/chrono/ChronoLocalDateTime.java + src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java + src/share/classes/java/time/chrono/ChronoZonedDateTime.java + src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java + src/share/classes/java/time/chrono/Chronology.java + src/share/classes/java/time/chrono/Era.java + src/share/classes/java/time/chrono/HijrahChronology.java + src/share/classes/java/time/chrono/HijrahDate.java + src/share/classes/java/time/chrono/HijrahDeviationReader.java + src/share/classes/java/time/chrono/HijrahEra.java + src/share/classes/java/time/chrono/IsoChronology.java + src/share/classes/java/time/chrono/IsoEra.java + src/share/classes/java/time/chrono/JapaneseChronology.java + src/share/classes/java/time/chrono/JapaneseDate.java + src/share/classes/java/time/chrono/JapaneseEra.java + src/share/classes/java/time/chrono/MinguoChronology.java + src/share/classes/java/time/chrono/MinguoDate.java + src/share/classes/java/time/chrono/MinguoEra.java + src/share/classes/java/time/chrono/Ser.java + src/share/classes/java/time/chrono/ThaiBuddhistChronology.java + src/share/classes/java/time/chrono/ThaiBuddhistDate.java + src/share/classes/java/time/chrono/ThaiBuddhistEra.java + src/share/classes/java/time/chrono/package-info.java ! src/share/classes/java/time/format/DateTimeBuilder.java ! src/share/classes/java/time/format/DateTimeFormatStyleProvider.java ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java - src/share/classes/java/time/format/DateTimeFormatters.java ! src/share/classes/java/time/format/DateTimeParseContext.java ! src/share/classes/java/time/format/DateTimePrintContext.java - src/share/classes/java/time/format/DateTimePrintException.java ! src/share/classes/java/time/format/DateTimeTextProvider.java ! src/share/classes/java/time/format/FormatStyle.java + src/share/classes/java/time/format/ZoneName.java ! src/share/classes/java/time/format/package-info.java ! src/share/classes/java/time/overview.html ! src/share/classes/java/time/package-info.java - src/share/classes/java/time/temporal/Chrono.java ! src/share/classes/java/time/temporal/ChronoField.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/temporal/ChronoUnit.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java + src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java ! src/share/classes/java/time/temporal/Queries.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalAccessor.java - src/share/classes/java/time/temporal/TemporalAdder.java ! src/share/classes/java/time/temporal/TemporalAdjuster.java + src/share/classes/java/time/temporal/TemporalAmount.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/TemporalQuery.java - src/share/classes/java/time/temporal/TemporalSubtractor.java ! src/share/classes/java/time/temporal/TemporalUnit.java ! src/share/classes/java/time/temporal/WeekFields.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java ! src/share/classes/java/time/temporal/package-info.java ! src/share/classes/java/time/zone/TzdbZoneRulesProvider.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/time/zone/ZoneRules.java ! src/share/classes/java/time/zone/ZoneRulesProvider.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Date.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/sun/text/resources/FormatData.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! src/share/classes/sun/text/resources/el/FormatData_el.java ! src/share/classes/sun/text/resources/hr/FormatData_hr.java ! src/share/classes/sun/text/resources/ja/FormatData_ja.java ! src/share/classes/sun/text/resources/ko/FormatData_ko.java ! src/share/classes/sun/text/resources/sr/FormatData_sr.java ! src/share/classes/sun/text/resources/sv/FormatData_sv.java ! src/share/classes/sun/text/resources/zh/FormatData_zh.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java ! src/share/classes/sun/util/calendar/CalendarSystem.java ! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java ! src/share/classes/sun/util/calendar/ZoneInfo.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java + test/java/sql/JavatimeTest.java + test/java/time/META-INF/services/java.time.chrono.Chronology - test/java/time/META-INF/services/java.time.temporal.Chrono ! test/java/time/tck/java/time/AbstractTCKTest.java + test/java/time/tck/java/time/MockSimplePeriod.java ! test/java/time/tck/java/time/TCKClock.java ! test/java/time/tck/java/time/TCKClock_Fixed.java ! test/java/time/tck/java/time/TCKClock_Offset.java ! test/java/time/tck/java/time/TCKClock_System.java ! test/java/time/tck/java/time/TCKClock_Tick.java ! test/java/time/tck/java/time/TCKDayOfWeek.java ! test/java/time/tck/java/time/TCKDuration.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKMonth.java + test/java/time/tck/java/time/TCKMonthDay.java + test/java/time/tck/java/time/TCKOffsetDateTime.java + test/java/time/tck/java/time/TCKOffsetTime.java + test/java/time/tck/java/time/TCKPeriod.java + test/java/time/tck/java/time/TCKYear.java + test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/time/tck/java/time/TCKZoneOffset.java ! test/java/time/tck/java/time/TCKZonedDateTime.java + test/java/time/tck/java/time/TestChronology.java + test/java/time/tck/java/time/TestIsoChronology.java - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java + test/java/time/tck/java/time/chrono/CopticChronology.java + test/java/time/tck/java/time/chrono/CopticDate.java + test/java/time/tck/java/time/chrono/CopticEra.java + test/java/time/tck/java/time/chrono/TCKChronology.java + test/java/time/tck/java/time/chrono/TCKTestServiceLoader.java + test/java/time/tck/java/time/chrono/TestChronoLocalDate.java + test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java + test/java/time/tck/java/time/chrono/TestHijrahChronology.java + test/java/time/tck/java/time/chrono/TestJapaneseChronology.java + test/java/time/tck/java/time/chrono/TestMinguoChronology.java + test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java + test/java/time/tck/java/time/format/TCKChronoPrinterParser.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatter.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java ! test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java ! test/java/time/tck/java/time/format/TCKLocalizedFieldParser.java ! test/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java + test/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java + test/java/time/tck/java/time/format/TCKOffsetPrinterParser.java + test/java/time/tck/java/time/format/TCKPadPrinterParser.java + test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java - test/java/time/tck/java/time/temporal/TCKISOFields.java + test/java/time/tck/java/time/temporal/TCKIsoFields.java ! test/java/time/tck/java/time/temporal/TCKJulianFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java ! test/java/time/tck/java/time/temporal/TestChronoLocalDate.java ! test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java ! test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java - test/java/time/tck/java/time/temporal/TestISOChrono.java ! test/java/time/tck/java/time/zone/TCKFixedZoneRules.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/TCKZoneRules.java ! test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java ! test/java/time/test/java/time/MockSimplePeriod.java ! test/java/time/test/java/time/TestDuration.java ! test/java/time/test/java/time/TestLocalDateTime.java ! test/java/time/test/java/time/TestLocalTime.java + test/java/time/test/java/time/TestMonthDay.java + test/java/time/test/java/time/TestOffsetDateTime.java + test/java/time/test/java/time/TestOffsetDateTime_instants.java + test/java/time/test/java/time/TestOffsetTime.java ! test/java/time/test/java/time/TestPeriod.java - test/java/time/test/java/time/TestPeriodParser.java + test/java/time/test/java/time/TestYear.java + test/java/time/test/java/time/TestYearMonth.java ! test/java/time/test/java/time/TestZoneId.java + test/java/time/test/java/time/chrono/TestExampleCode.java + test/java/time/test/java/time/chrono/TestIsoChronoImpl.java + test/java/time/test/java/time/chrono/TestServiceLoader.java ! test/java/time/test/java/time/format/TestCharLiteralParser.java ! test/java/time/test/java/time/format/TestCharLiteralPrinter.java + test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java ! test/java/time/test/java/time/format/TestDateTimeTextProvider.java ! test/java/time/test/java/time/format/TestFractionPrinterParser.java + test/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/java/time/test/java/time/format/TestNumberParser.java ! test/java/time/test/java/time/format/TestNumberPrinter.java - test/java/time/test/java/time/format/TestPadParserDecorator.java ! test/java/time/test/java/time/format/TestPadPrinterDecorator.java ! test/java/time/test/java/time/format/TestReducedParser.java ! test/java/time/test/java/time/format/TestReducedPrinter.java ! test/java/time/test/java/time/format/TestSettingsParser.java ! test/java/time/test/java/time/format/TestStringLiteralParser.java ! test/java/time/test/java/time/format/TestStringLiteralPrinter.java ! test/java/time/test/java/time/format/TestTextParser.java ! test/java/time/test/java/time/format/TestTextPrinter.java - test/java/time/test/java/time/format/TestZoneIdParser.java ! test/java/time/test/java/time/format/TestZoneOffsetParser.java ! test/java/time/test/java/time/format/TestZoneOffsetPrinter.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java + test/java/time/test/java/time/format/ZoneName.java ! test/java/time/test/java/time/temporal/MockFieldNoValue.java ! test/java/time/test/java/time/temporal/MockFieldValue.java ! test/java/time/test/java/time/temporal/TestChronoUnit.java ! test/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java ! test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java + test/java/time/test/java/time/temporal/TestJulianFields.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java ! test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java ! test/java/time/test/java/time/zone/TestFixedZoneRules.java ! test/java/time/test/java/util/TestFormatter.java + test/java/util/Calendar/JavatimeTest.java ! test/java/util/TimeZone/OldIDMappingTest.java + test/java/util/TimeZone/TzIDOldMapping.java + test/sun/util/calendar/zi/BackEnd.java + test/sun/util/calendar/zi/Checksum.java + test/sun/util/calendar/zi/DayOfWeek.java + test/sun/util/calendar/zi/Gen.java + test/sun/util/calendar/zi/GenDoc.java + test/sun/util/calendar/zi/Main.java + test/sun/util/calendar/zi/Mappings.java + test/sun/util/calendar/zi/Month.java + test/sun/util/calendar/zi/Rule.java + test/sun/util/calendar/zi/RuleDay.java + test/sun/util/calendar/zi/RuleRec.java + test/sun/util/calendar/zi/Simple.java + test/sun/util/calendar/zi/TestZoneInfo310.java + test/sun/util/calendar/zi/Time.java + test/sun/util/calendar/zi/Timezone.java + test/sun/util/calendar/zi/TzIDOldMapping.java + test/sun/util/calendar/zi/Zone.java + test/sun/util/calendar/zi/ZoneInfoFile.java + test/sun/util/calendar/zi/ZoneInfoOld.java + test/sun/util/calendar/zi/ZoneRec.java + test/sun/util/calendar/zi/Zoneinfo.java + test/sun/util/calendar/zi/tzdata/VERSION + test/sun/util/calendar/zi/tzdata/africa + test/sun/util/calendar/zi/tzdata/antarctica + test/sun/util/calendar/zi/tzdata/asia + test/sun/util/calendar/zi/tzdata/australasia + test/sun/util/calendar/zi/tzdata/backward + test/sun/util/calendar/zi/tzdata/etcetera + test/sun/util/calendar/zi/tzdata/europe + test/sun/util/calendar/zi/tzdata/factory + test/sun/util/calendar/zi/tzdata/gmt + test/sun/util/calendar/zi/tzdata/iso3166.tab + test/sun/util/calendar/zi/tzdata/jdk11_backward + test/sun/util/calendar/zi/tzdata/leapseconds + test/sun/util/calendar/zi/tzdata/northamerica + test/sun/util/calendar/zi/tzdata/pacificnew + test/sun/util/calendar/zi/tzdata/solar87 + test/sun/util/calendar/zi/tzdata/solar88 + test/sun/util/calendar/zi/tzdata/solar89 + test/sun/util/calendar/zi/tzdata/southamerica + test/sun/util/calendar/zi/tzdata/systemv + test/sun/util/calendar/zi/tzdata/zone.tab + test/sun/util/calendar/zi/tzdata_jdk/gmt + test/sun/util/calendar/zi/tzdata_jdk/jdk11_backward + test/sun/util/calendar/zi/tzdata_jdk/jdk11_full_backward Changeset: 2cd67a8c7abc Author: jfranck Date: 2013-02-13 10:36 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2cd67a8c7abc 8007278: Rename j.l.r.AnnotatedElement.getAnnotations(Class) to getAnnotationsByType(Class) Reviewed-by: darcy, abuckley ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Parameter.java ! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! test/java/lang/annotation/TypeParamAnnotation.java ! test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java Changeset: cd111064d4e9 Author: zgu Date: 2013-02-12 14:47 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/cd111064d4e9 8006691: Remove jvm_version_info->is_kernel_jvm field Summary: Remove is_kernel_jvm field in jvm_version_info structure, as kernel VM has been deprecated Reviewed-by: mchung ! src/share/javavm/export/jvm.h Changeset: bf64f83aa0cd Author: vinnie Date: 2013-02-13 16:01 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bf64f83aa0cd 8007934: algorithm parameters for PBE Scheme 2 not decoded correctly in PKCS12 keystore Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! test/java/security/KeyStore/PBETest.java Changeset: ceb7c712c693 Author: vinnie Date: 2013-02-13 16:03 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ceb7c712c693 Merge Changeset: 8181be9a3538 Author: dsamersoff Date: 2013-02-13 21:06 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8181be9a3538 8008095: TEST_BUG: JDK-8002048 one more testcase failure on Solaris Summary: fixed couple of more Solaris shell incompatibilities Reviewed-by: chegar ! test/sun/management/jdp/JdpTest.sh Changeset: 11438befdd4c Author: vinnie Date: 2013-02-13 19:40 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/11438befdd4c 8007755: Support the logical grouping of keystores Reviewed-by: mullan ! src/share/classes/java/security/KeyStore.java + src/share/classes/sun/security/provider/DomainKeyStore.java ! src/share/classes/sun/security/provider/PolicyParser.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/provider/SunEntries.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/provider/KeyStore/DKSTest.java + test/sun/security/provider/KeyStore/DKSTest.sh + test/sun/security/provider/KeyStore/domains.cfg ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/DummyProvider.java Changeset: efc66fe16f91 Author: sherman Date: 2013-02-13 11:49 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/efc66fe16f91 8008161: Regression: j.u.TimeZone.getAvailableIDs(rawOffset) returns non-sorted list Summary: to return a sorted list Reviewed-by: lancea, naoto ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! test/sun/util/calendar/zi/TestZoneInfo310.java Changeset: ff80a6b2ae9b Author: lana Date: 2013-02-13 11:25 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ff80a6b2ae9b Merge Changeset: a5aad284904e Author: lana Date: 2013-02-13 11:57 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a5aad284904e Merge Changeset: 83c09292f5ad Author: ksrini Date: 2013-02-13 12:56 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/83c09292f5ad 8005750: [parfait] Memory leak at jdk/src/share/bin/parse_manifest.c Reviewed-by: jjh ! src/share/bin/parse_manifest.c Changeset: b13247d5408d Author: dcubed Date: 2013-02-13 13:22 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b13247d5408d 8007935: java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh should use $COMPILEJAVA for javac Reviewed-by: sspitsyn, alanb ! test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh Changeset: 4f520ce7ba3f Author: acorn Date: 2013-02-13 16:09 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4f520ce7ba3f 8007888: jdk fix default method: VerifyError: Illegal use of nonvirtual Summary: Recognize VM generated method in old verifier. With 8004967 Reviewed-by: coleenp, acorn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/javavm/export/jvm.h ! src/share/native/common/check_code.c Changeset: e6f34051c60c Author: acorn Date: 2013-02-13 16:15 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e6f34051c60c Merge Changeset: dc3019a336c0 Author: lana Date: 2013-02-13 17:57 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/dc3019a336c0 Merge - src/share/classes/java/time/PeriodParser.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java - src/share/classes/java/time/format/DateTimeFormatters.java - src/share/classes/java/time/format/DateTimePrintException.java - src/share/classes/java/time/temporal/Chrono.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java - src/share/classes/java/time/temporal/TemporalAdder.java - src/share/classes/java/time/temporal/TemporalSubtractor.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java - test/java/time/META-INF/services/java.time.temporal.Chrono - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java - test/java/time/tck/java/time/temporal/TCKISOFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java - test/java/time/tck/java/time/temporal/TestISOChrono.java - test/java/time/test/java/time/TestPeriodParser.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java - test/java/time/test/java/time/format/TestPadParserDecorator.java - test/java/time/test/java/time/format/TestZoneIdParser.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java Changeset: 5ea0024ba765 Author: lana Date: 2013-02-14 22:12 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5ea0024ba765 Merge From david.katleman at oracle.com Fri Feb 15 19:59:20 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 15 Feb 2013 19:59:20 +0000 Subject: hg: jdk8/build/langtools: 20 new changesets Message-ID: <20130215200017.7D04A47B08@hg.openjdk.java.net> Changeset: bc24411bcc37 Author: katleman Date: 2013-02-14 11:44 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/bc24411bcc37 Added tag jdk8-b77 for changeset 89c664151689 ! .hgtags Changeset: de932285124c Author: jjg Date: 2013-02-05 21:55 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/de932285124c 8007485: test creates .class files in the test/ directory Reviewed-by: mcimadamore ! test/tools/javac/api/8007344/Test.java Changeset: 1df20330f6bd Author: mcimadamore Date: 2013-02-06 14:03 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/1df20330f6bd 8007463: Cleanup inference related classes Summary: Make Infer.InferenceContext an inner class; adjust bound replacement logic in Type.UndetVar Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/util/List.java ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/lib/DPrinter.java Changeset: 8cdd96f2fdb9 Author: mcimadamore Date: 2013-02-06 14:04 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/8cdd96f2fdb9 8007479: Refactor DeferredAttrContext so that it points to parent context Summary: Move DeferredAttrNode out of DeferredAttrContext; add support for nested deferred contexts Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: 153d20d0cac5 Author: jjg Date: 2013-02-06 07:49 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/153d20d0cac5 8007566: DocLint too aggressive with not allowed here:

Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/ParaTagTest.java Changeset: b386b8c45387 Author: jjh Date: 2013-02-06 23:10 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/b386b8c45387 8007698: jtreg test T6306137.java won't compile with ASCII encoding Reviewed-by: ksrini ! test/tools/javac/api/T6306137.java Changeset: 5125b9854d07 Author: darcy Date: 2013-02-07 20:47 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/5125b9854d07 7195131: Update 2 compiler combo tests for repeating annotations to include package and default use cases Reviewed-by: darcy Contributed-by: sonali.goel at oracle.com ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java + test/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java Changeset: 762d0af062f5 Author: vromero Date: 2013-02-08 09:12 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/762d0af062f5 7166455: javac doesn't set ACC_STRICT bit on for strictfp class Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/7166455/CheckACC_STRICTFlagOnclinitTest.java Changeset: b1deb90d2e37 Author: vromero Date: 2013-02-08 09:15 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/b1deb90d2e37 8005931: javac doesn't set ACC_STRICT for classes with package access Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/8005931/CheckACC_STRICTFlagOnPkgAccessClassTest.java Changeset: 017e8bdd440f Author: vromero Date: 2013-02-08 09:21 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/017e8bdd440f 7167125: Two variables after the same operation in a inner class return different results Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/7167125/DiffResultAfterSameOperationInnerClasses.java Changeset: 60caf53b98e2 Author: jjg Date: 2013-02-08 17:35 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/60caf53b98e2 8007610: javadoc doclint does not work with -private Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! test/com/sun/javadoc/T6735320/T6735320.java ! test/tools/javadoc/doclint/DocLintTest.java Changeset: 01af1b5c631d Author: darcy Date: 2013-02-11 13:37 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/01af1b5c631d 8007574: Provide isFunctionalInterface in javax.lang.model Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/javax/lang/model/element/TypeElement.java ! src/share/classes/javax/lang/model/util/Elements.java + test/tools/javac/processing/model/util/elements/TestIsFunctionalInterface.java Changeset: 973646bf043a Author: jfranck Date: 2013-02-12 11:28 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/973646bf043a 8004822: RFE to write language model API tests for repeating annotations based on the spec updates Reviewed-by: jjg, abuckley Contributed-by: Matherey Nunez + test/tools/javac/processing/model/element/repeatingAnnotations/ElementRepAnnoTester.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedA1Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedA2Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB1Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB2Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedA1Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedA2Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedB1Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedB2Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/OfficialContainerBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/OfficialContainerInheritedTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableInheritedTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOfficialContainerBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOfficialContainerInheritedTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideATest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideBTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/SingularBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/SingularInheritedATest.java + test/tools/javac/processing/model/element/repeatingAnnotations/SingularInheritedBTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/UnofficialContainerBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/UnofficialContainerInheritedTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/Bar.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarContainerContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarInherited.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarInheritedContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarInheritedContainerContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/ExpectedBase.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/ExpectedContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/Foo.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/FooInherited.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/UnofficialContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/UnofficialInheritedContainer.java Changeset: 073696f59241 Author: vromero Date: 2013-02-12 13:36 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/073696f59241 8006334: javap, JavapTask constructor breaks with null pointer exception if parameter options is null Reviewed-by: jjg ! src/share/classes/com/sun/tools/javap/JavapTask.java + test/tools/javap/8006334/JavapTaskCtorFailWithNPE.java Changeset: 2154ed9ff6c8 Author: mcimadamore Date: 2013-02-12 19:25 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/2154ed9ff6c8 8007464: Add graph inference support Summary: Add support for more aggressive type-inference scheme Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + src/share/classes/com/sun/tools/javac/util/GraphUtils.java ! test/tools/javac/6758789/T6758789b.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/diags/examples/CantApplyDiamond1.java ! test/tools/javac/diags/examples/InferredDoNotConformToEq.java ! test/tools/javac/diags/examples/InferredDoNotConformToUpper.java ! test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/generics/7015430/T7015430.out ! test/tools/javac/generics/7151802/T7151802.out ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/inference/6278587/T6278587Neg.java ! test/tools/javac/generics/inference/6638712/T6638712d.out ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/7154127/T7154127.java ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/generics/inference/7177306/T7177306a.out ! test/tools/javac/generics/inference/7177306/T7177306e.java ! test/tools/javac/generics/inference/7177306/T7177306e.out ! test/tools/javac/generics/odersky/BadTest4.java ! test/tools/javac/lambda/TargetType14.out ! test/tools/javac/lambda/TargetType20.java - test/tools/javac/lambda/TargetType20.out ! test/tools/javac/lambda/TargetType28.out ! test/tools/javac/lambda/TargetType50.java - test/tools/javac/lambda/TargetType50.out ! test/tools/javac/lambda/TargetType51.java ! test/tools/javac/lambda/TargetType52.java ! test/tools/javac/lambda/TargetType52.out + test/tools/javac/lambda/TargetType53.java + test/tools/javac/lambda/TargetType54.java + test/tools/javac/lambda/TargetType55.java + test/tools/javac/lambda/TargetType56.java + test/tools/javac/lambda/TargetType57.java + test/tools/javac/lambda/TargetType57.out + test/tools/javac/lambda/TargetType58.java + test/tools/javac/lambda/TargetType59.java + test/tools/javac/lambda/TargetType61.java + test/tools/javac/lambda/TargetType62.java Changeset: bc456436c613 Author: jjg Date: 2013-02-12 17:15 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/bc456436c613 8008077: update reference impl for type-annotations Reviewed-by: jjg Contributed-by: wmdietl at cs.washington.edu ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/TypeAnnotation.java ! src/share/classes/com/sun/tools/javac/code/TargetType.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java + test/tools/javac/annotations/typeAnnotations/failures/LazyConstantValue.java + test/tools/javac/annotations/typeAnnotations/failures/TypeVariable.java ! test/tools/javac/annotations/typeAnnotations/failures/VoidGenericMethod.java + test/tools/javac/annotations/typeAnnotations/newlocations/Lambda.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Lambda.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java Changeset: aeadaf905d78 Author: jfranck Date: 2013-02-13 10:33 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/aeadaf905d78 8007279: Rename javax.l.model.element.Element.getAnnotations(Class) to getAnnotationsByType(Class) Reviewed-by: darcy, abuckley ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/javax/lang/model/element/Element.java ! test/tools/javac/processing/model/element/repeatingAnnotations/ElementRepAnnoTester.java Changeset: d04960f05593 Author: mcimadamore Date: 2013-02-13 17:04 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/d04960f05593 8006345: Report Synthesized Parameters in java.lang.reflect.Parameter API 8006896: ClassReader doesn't see MethodParameters attr for method of anon inner class 8007098: Output Synthesized Parameters to MethodParameters Attributes Summary: Correctly report synthesized and mandated parameters Reviewed-by: mcimadamore, jjg Contributed-by: eric.mccorkle at oracle.com ! src/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: 3f9875aa5d67 Author: lana Date: 2013-02-13 11:25 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/3f9875aa5d67 Merge Changeset: a3aa32fe4536 Author: lana Date: 2013-02-14 22:11 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/a3aa32fe4536 Merge From sadhak001 at gmail.com Sat Feb 16 08:43:17 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Sat, 16 Feb 2013 08:43:17 +0000 Subject: Hotspot - kind of build and how to detect? In-Reply-To: <511E432B.4080009@oracle.com> References: <511DDE64.2030505@oracle.com> <511E0FD3.6070903@oracle.com> <511E3BAB.30901@oracle.com> <511E432B.4080009@oracle.com> Message-ID: Thanks David I will take it from here, I have found a couple of work-arounds to the below. Cheers, mani On Fri, Feb 15, 2013 at 2:16 PM, David Holmes wrote: > On 16/02/2013 12:09 AM, Mani Sarkar wrote: > >> I have written a bash script which looks for gamma, but gamma can be >> created using different make parameters resulting in 'gamma' being >> created in a nested folders (with various name combinations). I have >> figured a way to locate gamma but it would be best to be able use the >> data available to configure. >> > > configure doesn't know where gamma will be. hotspot makefile make that > decision. > > > With regards to your comment on make, is it not possible to write these >> values once they are available (post build) into environment variables - >> or as you saying we cannot write them into environment variables at all. >> > > It is not the job of a Makefile to export environment variables back to > the parent process. > > But you are free to modify the makefiles to expose this value of GAMMA for > your own needs. > > David > > Cheers, >> mani >> >> On Fri, Feb 15, 2013 at 1:44 PM, David Holmes > >> wrote: >> >> On 15/02/2013 9:42 PM, Mani Sarkar wrote: >> >> Thanks David, I appreciate your help so far. I'm devising a way >> around >> the below you mentioned. >> >> Would it be possible in future releases of your specs / scripts >> to echo >> these values (and other useful ones) out into the OS as >> environment >> variables, it would defo help with utilities or scripts running >> around >> the OpenJDK program - similar to the one I'm working on atm. >> >> >> I'm not sure what you are suggesting. configure generates makefiles >> with make variables. It doesn't set environment variables - nor is >> there a way to do so. Many of the variables do not have a value >> until make is run during an actual build. So I really don't know >> what you are asking for. >> >> David >> >> Cheers, >> mani >> >> >> -- >> *Twitter:* @theNeomatrix369 >> *Blog:* http://neomatrix369.wordpress.**com >> *JUG activity:* LJC Advocate >> *Meet-a-Project:* https://github.com/**MutabilityDetector >> *Come to Devoxx UK 2013:* http://www.devoxx.com/display/**UK13/Home >> */Don't chase success, rather aim for "Excellence", and success will >> come chasing after you!/* >> > -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate *Meet-a-Project:* https://github.com/MutabilityDetector *Come to Devoxx UK 2013:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From tim.bell at oracle.com Sat Feb 16 18:36:15 2013 From: tim.bell at oracle.com (Tim Bell) Date: Sat, 16 Feb 2013 10:36:15 -0800 Subject: Review Request: 8008294: build-infra: Build-infra closed fails on solaris 11.1 In-Reply-To: <511E43E8.1000403@oracle.com> References: <511E31F5.8010805@oracle.com> <511E3909.7000200@oracle.com> <511E422D.9080805@oracle.com> <511E43E8.1000403@oracle.com> Message-ID: <511FD19F.6050203@oracle.com> On 02/15/13 06:19, David Holmes wrote: > On 16/02/2013 12:11 AM, Erik Joelsson wrote: >> On 2013-02-15 14:32, David Holmes wrote: >>> Erik, >>> >>> On 15/02/2013 11:02 PM, Erik Joelsson wrote: >>>> Small patch to enable building with a newer compiler on Solaris when >>>> closed is available. The open part of this was fixed previously in >>>> 8002365. The patch adds '-lc' to the link lines for solaris. >>> >>> I don't understand your references to open and closed here. >>> >>> David >>> >> I guess I wrote that too fast. In the bug referenced above, similar -lc >> parameters were added to most (if not all) library link lines that are >> part of openjdk. This patch complements those changes by adding -lc to >> the libraries which still have their make logic in the open but source >> in closed. > > Got it - thanks. Looks okay. > > David Looks good to me as well. Tim > >> /Erik >> >>>> http://cr.openjdk.java.net/~erikj/8008294/webrev.jdk.01/ >>>> >>>> /Erik From tim.bell at oracle.com Sat Feb 16 18:42:04 2013 From: tim.bell at oracle.com (Tim Bell) Date: Sat, 16 Feb 2013 10:42:04 -0800 Subject: Review Request: 8008295: build-infra: Cleanup in Import.gmk In-Reply-To: References: <511E36BF.7030104@oracle.com> Message-ID: <511FD2FC.9040808@oracle.com> Hi Erik- Looks good to me as well. Tim On 02/15/13 05:55, Fredrik ?hrstr?m wrote: > ok > > 2013/2/15 Erik Joelsson : >> Cleaning up in jdk/makefiles/Import.gmk. Removing two copies of the >> install-file macro which is already defined in >> common/makefiles/MakeBase.gmk. >> >> http://cr.openjdk.java.net/~erikj/8008295/webrev.jdk.01/ >> >> /Erik From erik.joelsson at oracle.com Mon Feb 18 11:19:03 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 18 Feb 2013 12:19:03 +0100 Subject: Review Request: 8004352: build-infra: Limit JOBS on large machines In-Reply-To: <97C179D7-3CD4-4213-AA39-A61E735D7136@oracle.com> References: <511E24B6.2040309@oracle.com> <97C179D7-3CD4-4213-AA39-A61E735D7136@oracle.com> Message-ID: <51220E27.8090509@oracle.com> On 2013-02-15 18:12, Mike Duigou wrote: > A couple of comments; > > - Can you reverse steps #2 and #3? Having the hard cap last makes more sense. I agree and will do. > - In JDK-8007327 I requested some memory size definitions such as MEMORY_SIZE_NORMAL_HEAP for sizing of JVM heaps. The explicit "1000" should probably be replaced with the MEMORY_SIZE_NORMAL_HEAP constant. Elsewhere the value is "1100". > I can't find any other reference to this constant, but I can certainly change it to 1100. I just wanted something lower than 1024 since the reported amount of memory in a machine is usually somewhat lower than the exact multiple of 2 and the division is rounded down. > - The CONCURRENT_BUILD_JOBS is no longer JOBS * 2. Do we think that's right? I think it's correct that you can squeeze out a bit more performance from the hotspot (or jdk native) build by using cores * 2 as number of jobs, but any value higher than cores will affect the third bullet point below (don't interfere with my browser experience while I'm building). I also found it weird to have a different setting for hotspot and the jdk native build and thought this a good opportunity to unify the settings. The problem is that if someone increases JOBS to cores * 2 for maximum speed, there will most likely be problems in the java source generation in the jdk, which is more memory intensive. My assumption is that the speed loss from cores * 2 to cores * 1 is small enough to not matter much. We could fix this, but I'm not sure it's worth the effort. The user just wants to say something like, "go full speed while I make coffee", "leave some room so my terminal doesn't lock up" or "I'm running 4 builds in parallel, tune it down please". This could be expressed as a percentage, with a suitable default. For each part of the build, where we make a submake call, we can add a call to calculate a suitable value for the -j flag. Input is a factor indicating memory to cpu requirements, the factor from the user (set at configure or at make invocation), the number of cpus (from configure) and the amount of memory (from configure). /Erik > Mike > > On Feb 15 2013, at 04:06 , Erik Joelsson wrote: > >> The current default for number of parallel build jobs is just equal to the number of cores in the system. While this works well on many machines, there have been several reports of this not working. I have been trying to come up with a better scheme for the default and the following is something that I think will do. It has been active in the build-infra forest for a while now. >> >> The complaints that were raised were usually concerning one of the following: >> >> * A big machine with very many cpus didn't scale well when using all of them, so there is no point in trying to, it just made the build less stable. Suggestion, introduce a hard cap. >> * A machine with lots of cpus but not as much memory would run out of memory. Suggestion, limit number of jobs on memory as well as cpus. >> * The build eats up all my resources, leaving my browser unusable. Suggestion, don't use everything unless asked for. >> >> So this is what I ended up with: >> 1. Take the min of num_cores and memory_size/1000 >> 2. Cap at 16 >> 3. If more than 4 cores, shave it to 90% rounded down to leave some room. >> >> The user can still override this in two ways. Either by using any of the configure arguments: >> >> --with-num-cores number of cores in the build system, e.g. >> --with-num-cores=8 [probed] >> --with-memory-size memory (in MB) available in the build system, e.g. >> --with-memory-size=1024 [probed] >> --with-jobs number of parallel jobs to let make run [calculated >> based on cores and memory] >> >> Or by setting JOBS= on the make command line. >> >> Also not that this change will set the CONCURRENT_BUILD_JOBS for hotspot to the value of JOBS so that it too will be overridden by the above. >> >> http://cr.openjdk.java.net/~erikj/8004352/webrev.root.01/ >> >> /Erik From erik.joelsson at oracle.com Mon Feb 18 11:58:51 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 18 Feb 2013 12:58:51 +0100 Subject: Review Request: 8004352: build-infra: Limit JOBS on large machines In-Reply-To: <51220E27.8090509@oracle.com> References: <511E24B6.2040309@oracle.com> <97C179D7-3CD4-4213-AA39-A61E735D7136@oracle.com> <51220E27.8090509@oracle.com> Message-ID: <5122177B.2030003@oracle.com> New webrev: http://cr.openjdk.java.net/~erikj/8004352/webrev.root.02/ Moved the cap last. Changed the 1000 to 1100. Also scaling down to 90% is only done when cores is the limiting factor. I read your bug and now I understand what you mean about the constants. I agree that would be a good idea. /Erik On 2013-02-18 12:19, Erik Joelsson wrote: > > > On 2013-02-15 18:12, Mike Duigou wrote: >> A couple of comments; >> >> - Can you reverse steps #2 and #3? Having the hard cap last makes >> more sense. > I agree and will do. >> - In JDK-8007327 I requested some memory size definitions such as >> MEMORY_SIZE_NORMAL_HEAP for sizing of JVM heaps. The explicit "1000" >> should probably be replaced with the MEMORY_SIZE_NORMAL_HEAP >> constant. Elsewhere the value is "1100". >> > I can't find any other reference to this constant, but I can certainly > change it to 1100. I just wanted something lower than 1024 since the > reported amount of memory in a machine is usually somewhat lower than > the exact multiple of 2 and the division is rounded down. >> - The CONCURRENT_BUILD_JOBS is no longer JOBS * 2. Do we think that's >> right? > I think it's correct that you can squeeze out a bit more performance > from the hotspot (or jdk native) build by using cores * 2 as number of > jobs, but any value higher than cores will affect the third bullet > point below (don't interfere with my browser experience while I'm > building). I also found it weird to have a different setting for > hotspot and the jdk native build and thought this a good opportunity > to unify the settings. > > The problem is that if someone increases JOBS to cores * 2 for maximum > speed, there will most likely be problems in the java source > generation in the jdk, which is more memory intensive. My assumption > is that the speed loss from cores * 2 to cores * 1 is small enough to > not matter much. > > We could fix this, but I'm not sure it's worth the effort. The user > just wants to say something like, "go full speed while I make coffee", > "leave some room so my terminal doesn't lock up" or "I'm running 4 > builds in parallel, tune it down please". This could be expressed as a > percentage, with a suitable default. For each part of the build, where > we make a submake call, we can add a call to calculate a suitable > value for the -j flag. Input is a factor indicating memory to cpu > requirements, the factor from the user (set at configure or at make > invocation), the number of cpus (from configure) and the amount of > memory (from configure). > > /Erik >> Mike >> >> On Feb 15 2013, at 04:06 , Erik Joelsson wrote: >> >>> The current default for number of parallel build jobs is just equal >>> to the number of cores in the system. While this works well on many >>> machines, there have been several reports of this not working. I >>> have been trying to come up with a better scheme for the default and >>> the following is something that I think will do. It has been active >>> in the build-infra forest for a while now. >>> >>> The complaints that were raised were usually concerning one of the >>> following: >>> >>> * A big machine with very many cpus didn't scale well when using all >>> of them, so there is no point in trying to, it just made the build >>> less stable. Suggestion, introduce a hard cap. >>> * A machine with lots of cpus but not as much memory would run out >>> of memory. Suggestion, limit number of jobs on memory as well as cpus. >>> * The build eats up all my resources, leaving my browser unusable. >>> Suggestion, don't use everything unless asked for. >>> >>> So this is what I ended up with: >>> 1. Take the min of num_cores and memory_size/1000 >>> 2. Cap at 16 >>> 3. If more than 4 cores, shave it to 90% rounded down to leave some >>> room. >>> >>> The user can still override this in two ways. Either by using any of >>> the configure arguments: >>> >>> --with-num-cores number of cores in the build system, e.g. >>> --with-num-cores=8 [probed] >>> --with-memory-size memory (in MB) available in the build >>> system, e.g. >>> --with-memory-size=1024 [probed] >>> --with-jobs number of parallel jobs to let make run >>> [calculated >>> based on cores and memory] >>> >>> Or by setting JOBS= on the make command line. >>> >>> Also not that this change will set the CONCURRENT_BUILD_JOBS for >>> hotspot to the value of JOBS so that it too will be overridden by >>> the above. >>> >>> http://cr.openjdk.java.net/~erikj/8004352/webrev.root.01/ >>> >>> /Erik From erik.joelsson at oracle.com Mon Feb 18 16:22:55 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 18 Feb 2013 16:22:55 +0000 Subject: hg: jdk8/build: 2 new changesets Message-ID: <20130218162256.38F2B47B65@hg.openjdk.java.net> Changeset: ffb4d2e95140 Author: erikj Date: 2013-02-15 10:40 +0100 URL: http://hg.openjdk.java.net/jdk8/build/rev/ffb4d2e95140 8005879: Add -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 to builds on Mac Reviewed-by: ohair ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: b0642df54d63 Author: erikj Date: 2013-02-18 10:46 +0100 URL: http://hg.openjdk.java.net/jdk8/build/rev/b0642df54d63 Merge From erik.joelsson at oracle.com Mon Feb 18 16:23:28 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 18 Feb 2013 16:23:28 +0000 Subject: hg: jdk8/build/jdk: 4 new changesets Message-ID: <20130218162443.0335247B66@hg.openjdk.java.net> Changeset: 90707943f83c Author: erikj Date: 2013-02-15 10:41 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/90707943f83c 8005879: Add -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 to builds on Mac Reviewed-by: ohair ! make/common/Defs-macosx.gmk Changeset: 9a693ebd5595 Author: erikj Date: 2013-02-18 10:48 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9a693ebd5595 Merge - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java - src/share/classes/java/time/PeriodParser.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java - src/share/classes/java/time/format/DateTimeFormatters.java - src/share/classes/java/time/format/DateTimePrintException.java - src/share/classes/java/time/temporal/Chrono.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java - src/share/classes/java/time/temporal/TemporalAdder.java - src/share/classes/java/time/temporal/TemporalSubtractor.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java - test/java/time/META-INF/services/java.time.temporal.Chrono - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java - test/java/time/tck/java/time/temporal/TCKISOFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java - test/java/time/tck/java/time/temporal/TestISOChrono.java - test/java/time/test/java/time/TestPeriodParser.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java - test/java/time/test/java/time/format/TestPadParserDecorator.java - test/java/time/test/java/time/format/TestZoneIdParser.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java Changeset: fb7e3edf22b2 Author: erikj Date: 2013-02-18 11:26 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fb7e3edf22b2 8008294: build-infra: Build-infra closed fails on solaris 11.1 Reviewed-by: ohrstrom, dholmes, tbell ! makefiles/CompileDemos.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: a23b0df73324 Author: erikj Date: 2013-02-18 11:27 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a23b0df73324 8008295: build-infra: Cleanup in Import.gmk Reviewed-by: ohrstrom, tbell ! makefiles/Import.gmk From david.holmes at oracle.com Tue Feb 19 01:21:04 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 19 Feb 2013 01:21:04 +0000 Subject: hg: jdk8/build: 6 new changesets Message-ID: <20130219012104.89BF347B7D@hg.openjdk.java.net> Changeset: b80abec66e70 Author: bpatel Date: 2013-01-21 00:29 -0500 URL: http://hg.openjdk.java.net/jdk8/build/rev/b80abec66e70 8006124: javadoc/doclet should be updated to support profiles Reviewed-by: jjg, dholmes ! common/makefiles/javadoc/Javadoc.gmk Changeset: 7ed0c9db6943 Author: dholmes Date: 2013-01-21 01:50 -0500 URL: http://hg.openjdk.java.net/jdk8/build/rev/7ed0c9db6943 8004265: Add build support for Compact Profiles Reviewed-by: erikj, ohair ! NewMakefile.gmk ! common/autoconf/generated-configure.sh ! common/makefiles/Main.gmk Changeset: 2f8fd30f02e6 Author: dholmes Date: 2013-01-22 19:30 -0500 URL: http://hg.openjdk.java.net/jdk8/build/rev/2f8fd30f02e6 Merge ! common/autoconf/generated-configure.sh Changeset: bebeaa04ab8e Author: dholmes Date: 2013-02-04 18:08 -0500 URL: http://hg.openjdk.java.net/jdk8/build/rev/bebeaa04ab8e Merge ! common/autoconf/generated-configure.sh ! common/makefiles/javadoc/Javadoc.gmk Changeset: 28071e4ca1de Author: dholmes Date: 2013-02-17 16:44 -0500 URL: http://hg.openjdk.java.net/jdk8/build/rev/28071e4ca1de Merge ! common/autoconf/generated-configure.sh ! common/makefiles/Main.gmk Changeset: fd1a5574cf68 Author: dholmes Date: 2013-02-18 15:35 -0500 URL: http://hg.openjdk.java.net/jdk8/build/rev/fd1a5574cf68 Merge ! common/autoconf/generated-configure.sh From david.holmes at oracle.com Tue Feb 19 01:26:16 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 19 Feb 2013 01:26:16 +0000 Subject: hg: jdk8/build/langtools: 4 new changesets Message-ID: <20130219012630.A204447B7F@hg.openjdk.java.net> Changeset: 5f0731e4e5e6 Author: bpatel Date: 2013-01-21 00:45 -0500 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/5f0731e4e5e6 8006124: javadoc/doclet should be updated to support profiles Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/AbstractProfileIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java + src/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/ProfilePackageSummaryWriter.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/ProfileSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfilePackageSummaryBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfileSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java + test/com/sun/javadoc/testProfiles/TestProfiles.java + test/com/sun/javadoc/testProfiles/pkg1/Class1Pkg1.java + test/com/sun/javadoc/testProfiles/pkg1/Class2Pkg1.java + test/com/sun/javadoc/testProfiles/pkg1/Class3Pkg1.java + test/com/sun/javadoc/testProfiles/pkg1/Interface1Pkg1.java + test/com/sun/javadoc/testProfiles/pkg2/Anno1Pkg2.java + test/com/sun/javadoc/testProfiles/pkg2/Anno2Pkg2.java + test/com/sun/javadoc/testProfiles/pkg2/Class1Pkg2.java + test/com/sun/javadoc/testProfiles/pkg3/Class1Pkg3.java + test/com/sun/javadoc/testProfiles/pkg3/Class2Pkg3.java + test/com/sun/javadoc/testProfiles/pkg3/Interface1Pkg3.java + test/com/sun/javadoc/testProfiles/pkg4/Anno1Pkg4.java + test/com/sun/javadoc/testProfiles/pkg4/Class1Pkg4.java + test/com/sun/javadoc/testProfiles/pkg5/Class1Pkg5.java + test/com/sun/javadoc/testProfiles/pkg5/Interface1Pkg5.java + test/com/sun/javadoc/testProfiles/profile-rtjar-includes.txt Changeset: 475eb15dfdad Author: jjg Date: 2013-01-21 01:27 -0500 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/475eb15dfdad 8004182: Add support for profiles in javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + src/share/classes/com/sun/tools/javac/jvm/Profile.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java + src/share/classes/com/sun/tools/javac/sym/Profiles.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/diags/examples/NotInProfile.java + test/tools/javac/profiles/ProfileOptionTest.java Changeset: f91144b7da75 Author: dholmes Date: 2013-02-04 18:08 -0500 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/f91144b7da75 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java - test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java - test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java - test/tools/javac/diags/examples/ContainedByInheritedMismatch.java - test/tools/javac/diags/examples/ContainedByNoValue.java - test/tools/javac/diags/examples/ContainedByNonDefault.java - test/tools/javac/diags/examples/ContainedByRetentionMismatch.java - test/tools/javac/diags/examples/ContainedByTargetMismatch.java - test/tools/javac/diags/examples/ContainedByWrongValueType.java - test/tools/javac/diags/examples/InferredDoNotConformToLower.java - test/tools/javac/diags/examples/NoUniqueMaximalInstance.java - test/tools/javac/diags/examples/WrongContainedBy.java - test/tools/javac/diags/examples/WrongContainerFor.java - test/tools/javac/lambda/MethodReference26.out - test/tools/javac/lambda/TargetType06.out - test/tools/javac/lambda/TargetType11.out - test/tools/javac/lambda/TargetType45.out - test/tools/javac/lambda/VoidCompatibility.out - test/tools/javac/typeAnnotations/newlocations/BasicTest.java - test/tools/javac/typeAnnotations/newlocations/BasicTest.out Changeset: af8417e590f4 Author: dholmes Date: 2013-02-17 16:44 -0500 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/af8417e590f4 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java - test/tools/javac/lambda/TargetType20.out - test/tools/javac/lambda/TargetType50.out From david.holmes at oracle.com Tue Feb 19 01:22:52 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 19 Feb 2013 01:22:52 +0000 Subject: hg: jdk8/build/jdk: 14 new changesets Message-ID: <20130219012541.659F447B7E@hg.openjdk.java.net> Changeset: 32549d339437 Author: bpatel Date: 2013-01-21 00:31 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/32549d339437 8006124: javadoc/doclet should be updated to support profiles Reviewed-by: jjg, dholmes ! make/docs/Makefile Changeset: 80afadbf967d Author: alanb Date: 2013-01-21 01:46 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/80afadbf967d 8004182: Add support for profiles in javac Reviewed-by: dholmes ! make/common/Release.gmk Changeset: 353b88963430 Author: dholmes Date: 2013-01-21 21:54 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/353b88963430 8006651: build-infra: Import.gmk needs to add support for the minimal VM Reviewed-by: erikj, ohair ! makefiles/Import.gmk Changeset: 7096f51288ab Author: dholmes Date: 2013-01-21 23:17 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7096f51288ab 8004265: Add build support for Compact Profiles Reviewed-by: erikj, ohair ! make/tools/src/build/tools/jarreorder/JarReorder.java ! makefiles/BuildJdk.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk + makefiles/ProfileNames.gmk + makefiles/Profiles.gmk Changeset: ccd0aceb1190 Author: alanb Date: 2013-01-21 23:20 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ccd0aceb1190 8003255: (profiles) Update JAR file specification to support profiles Reviewed-by: dholmes, mchung, ksrini ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/util/jar/Attributes.java + src/share/classes/java/util/jar/UnsupportedProfileException.java ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/misc/URLClassPath.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jar/resources/jar.properties + test/java/net/URLClassLoader/profiles/Basic.java + test/java/net/URLClassLoader/profiles/Lib.java + test/java/net/URLClassLoader/profiles/basic.sh + test/tools/jar/AddAndUpdateProfile.java + test/tools/launcher/profiles/Basic.java + test/tools/launcher/profiles/Logging.java + test/tools/launcher/profiles/Main.java Changeset: c024147205f6 Author: alanb Date: 2013-01-21 23:21 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c024147205f6 8003256: (profiles) Add support for profile identification Reviewed-by: dholmes, mchung, ksrini ! make/java/version/Makefile ! makefiles/GensrcMisc.gmk ! src/share/classes/sun/misc/Version.java.template + test/tools/launcher/profiles/VersionCheck.java Changeset: 4b3434f5f509 Author: alanb Date: 2013-01-21 23:23 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4b3434f5f509 8004931: add/removePropertyChangeListener should not exist in subset Profiles of Java SE Reviewed-by: dholmes, mchung, ksrini + make/tools/src/build/tools/RemoveMethods.java ! makefiles/Tools.gmk ! src/share/classes/java/util/jar/Pack200.java ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/Reflect.java + test/tools/pack200/NoBeans.java + test/tools/pack200/Reflect.java Changeset: d9cfe581c8fe Author: alanb Date: 2013-01-21 23:35 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d9cfe581c8fe 8004502: Compact Profiles contents Reviewed-by: dholmes, mchung + makefiles/profile-includes.txt + makefiles/profile-rtjar-includes.txt + test/java/lang/SecurityManager/NoAWT.java + test/java/security/cert/CertStore/NoLDAP.java + test/javax/management/remote/mandatory/connection/NoIIOP.java + test/javax/naming/InitialContext/NoApplet.java + test/sun/net/www/protocol/http/NoNTLM.java + test/sun/security/ssl/sanity/ciphersuites/NoKerberos.java Changeset: d1b29d290ebd Author: dholmes Date: 2013-01-22 19:31 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d1b29d290ebd Merge Changeset: 0918d6d9c18b Author: dholmes Date: 2013-01-22 20:04 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0918d6d9c18b 8006667: Merge issue: Profile attribute need to be examined before custom attributes Summary: swap profile checking and FXHelper checking Reviewed-by: alanb ! src/share/classes/sun/launcher/LauncherHelper.java Changeset: 77668918a388 Author: dholmes Date: 2013-02-04 18:08 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/77668918a388 Merge ! make/docs/Makefile ! makefiles/CreateJars.gmk ! makefiles/GensrcMisc.gmk ! makefiles/Tools.gmk ! src/share/classes/sun/misc/URLClassPath.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/CallbackInterface.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/Callback_Stub.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup_Stub.java Changeset: f308a689c049 Author: dholmes Date: 2013-02-17 16:44 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f308a689c049 Merge ! makefiles/Tools.gmk - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java - src/share/classes/java/time/PeriodParser.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java - src/share/classes/java/time/format/DateTimeFormatters.java - src/share/classes/java/time/format/DateTimePrintException.java - src/share/classes/java/time/temporal/Chrono.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java - src/share/classes/java/time/temporal/TemporalAdder.java - src/share/classes/java/time/temporal/TemporalSubtractor.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java - test/java/net/URL/abnormal_http_urls - test/java/net/URL/ftp_urls - test/java/net/URL/jar_urls - test/java/net/URL/normal_http_urls - test/java/net/URL/runconstructor.sh - test/java/net/URL/share_file_urls - test/java/net/URL/win32_file_urls - test/java/time/META-INF/services/java.time.temporal.Chrono - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java - test/java/time/tck/java/time/temporal/TCKISOFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java - test/java/time/tck/java/time/temporal/TestISOChrono.java - test/java/time/test/java/time/TestPeriodParser.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java - test/java/time/test/java/time/format/TestPadParserDecorator.java - test/java/time/test/java/time/format/TestZoneIdParser.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java - test/sun/net/www/EncDec.doc - test/sun/net/www/MarkResetTest.java - test/sun/net/www/MarkResetTest.sh - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java Changeset: 16c684b2ab82 Author: alanb Date: 2013-02-18 08:57 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/16c684b2ab82 8007436: (profiles) Add JSR-310 to Compact Profiles contents Reviewed-by: dholmes, erikj ! makefiles/profile-includes.txt ! makefiles/profile-rtjar-includes.txt Changeset: c24bc91caa67 Author: dholmes Date: 2013-02-18 15:35 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c24bc91caa67 Merge ! makefiles/Import.gmk From david.holmes at oracle.com Tue Feb 19 01:54:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Feb 2013 11:54:21 +1000 Subject: JEP 161 SE Compact Profiles has pushed to jdk8/build forest Message-ID: <5122DB4D.4020302@oracle.com> The implementation support for the Reference Implementation of the SE Compact Profiles described by: http://openjdk.java.net/jeps/161 has now been pushed to the jdk8/build forest ready for integration with jdk8/jdk8 in time for b78. This reference implementation is for the Linux platform only. To build the compact profiles JREs specify the "profiles" target to make: make profiles or to build the full JDK/JRE and profile images use: make images profiles Profiles are not built by default ("make all"). The Profile JRE's are created in the images directory along side the j2re-image and j2sdk-image, and are named j2re-compactN-image, for N=1,2,3 One minor issue we just became aware of (bug 8008424), don't have the variable PROFILE set in your environment when building the "images" target. Workaround is to either unset the env variable before calling make, or pass PROFILE="" as a make argument when building. This will be fixed ASAP. David Holmes ------------- From david.holmes at oracle.com Tue Feb 19 02:36:00 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Feb 2013 12:36:00 +1000 Subject: XS RFR: 8008424: Isolate PROFILE make variable from incidental setting in the environment Message-ID: <5122E510.8040301@oracle.com> A very simple follow up fix for the Profiles work that prevents a conflict between an unrelated environment variable and the make variable: http://cr.openjdk.java.net/~dholmes/8008424/webrev/ Inline: --- old/makefiles/BuildJdk.gmk 2013-02-18 21:32:55.022943673 -0500 +++ new/makefiles/BuildJdk.gmk 2013-02-18 21:32:53.698869592 -0500 @@ -91,10 +91,11 @@ +$(MAKE) -f CopySamples.gmk # Create the final jdk and jre images, to be wrapped up -# into packages, or installed. +# into packages, or installed. Ensure PROFILE is not set +# in these cases. images: - +$(MAKE) -f CreateJars.gmk - +$(MAKE) -f Images.gmk + +$(MAKE) PROFILE="" -f CreateJars.gmk + +$(MAKE) PROFILE="" -f Images.gmk ifeq ($(OPENJDK_TARGET_OS), macosx) +$(MAKE) -f Bundles.gmk endif Thanks, David From erik.joelsson at oracle.com Tue Feb 19 08:27:54 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 19 Feb 2013 09:27:54 +0100 Subject: XS RFR: 8008424: Isolate PROFILE make variable from incidental setting in the environment In-Reply-To: <5122E510.8040301@oracle.com> References: <5122E510.8040301@oracle.com> Message-ID: <5123378A.7070802@oracle.com> Looks good to me. /Erik On 2013-02-19 03:36, David Holmes wrote: > A very simple follow up fix for the Profiles work that prevents a > conflict between an unrelated environment variable and the make variable: > > http://cr.openjdk.java.net/~dholmes/8008424/webrev/ > > Inline: > > --- old/makefiles/BuildJdk.gmk 2013-02-18 21:32:55.022943673 -0500 > +++ new/makefiles/BuildJdk.gmk 2013-02-18 21:32:53.698869592 -0500 > @@ -91,10 +91,11 @@ > +$(MAKE) -f CopySamples.gmk > > # Create the final jdk and jre images, to be wrapped up > -# into packages, or installed. > +# into packages, or installed. Ensure PROFILE is not set > +# in these cases. > images: > - +$(MAKE) -f CreateJars.gmk > - +$(MAKE) -f Images.gmk > + +$(MAKE) PROFILE="" -f CreateJars.gmk > + +$(MAKE) PROFILE="" -f Images.gmk > ifeq ($(OPENJDK_TARGET_OS), macosx) > +$(MAKE) -f Bundles.gmk > endif > > > Thanks, > David From david.holmes at oracle.com Tue Feb 19 09:20:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Feb 2013 19:20:04 +1000 Subject: XS RFR: 8008424: Isolate PROFILE make variable from incidental setting in the environment In-Reply-To: <5123378A.7070802@oracle.com> References: <5122E510.8040301@oracle.com> <5123378A.7070802@oracle.com> Message-ID: <512343C4.3080508@oracle.com> On 19/02/2013 6:27 PM, Erik Joelsson wrote: > Looks good to me. Thanks Erik. I guess I also need a jdk8 Reviewer ? David > /Erik > > On 2013-02-19 03:36, David Holmes wrote: >> A very simple follow up fix for the Profiles work that prevents a >> conflict between an unrelated environment variable and the make variable: >> >> http://cr.openjdk.java.net/~dholmes/8008424/webrev/ >> >> Inline: >> >> --- old/makefiles/BuildJdk.gmk 2013-02-18 21:32:55.022943673 -0500 >> +++ new/makefiles/BuildJdk.gmk 2013-02-18 21:32:53.698869592 -0500 >> @@ -91,10 +91,11 @@ >> +$(MAKE) -f CopySamples.gmk >> >> # Create the final jdk and jre images, to be wrapped up >> -# into packages, or installed. >> +# into packages, or installed. Ensure PROFILE is not set >> +# in these cases. >> images: >> - +$(MAKE) -f CreateJars.gmk >> - +$(MAKE) -f Images.gmk >> + +$(MAKE) PROFILE="" -f CreateJars.gmk >> + +$(MAKE) PROFILE="" -f Images.gmk >> ifeq ($(OPENJDK_TARGET_OS), macosx) >> +$(MAKE) -f Bundles.gmk >> endif >> >> >> Thanks, >> David From Alan.Bateman at oracle.com Tue Feb 19 09:32:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Feb 2013 09:32:11 +0000 Subject: XS RFR: 8008424: Isolate PROFILE make variable from incidental setting in the environment In-Reply-To: <512343C4.3080508@oracle.com> References: <5122E510.8040301@oracle.com> <5123378A.7070802@oracle.com> <512343C4.3080508@oracle.com> Message-ID: <5123469B.1090002@oracle.com> On 19/02/2013 09:20, David Holmes wrote: > On 19/02/2013 6:27 PM, Erik Joelsson wrote: >> Looks good to me. > > Thanks Erik. I guess I also need a jdk8 Reviewer ? > > David It looks fine to me too. -Alan. From david.holmes at oracle.com Tue Feb 19 11:28:03 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 19 Feb 2013 11:28:03 +0000 Subject: hg: jdk8/build/jdk: 8008424: Isolate PROFILE make variable from incidental setting in the environment Message-ID: <20130219112827.72E3847B90@hg.openjdk.java.net> Changeset: b46c75e221c7 Author: dholmes Date: 2013-02-19 06:27 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b46c75e221c7 8008424: Isolate PROFILE make variable from incidental setting in the environment Reviewed-by: erikj, alanb ! makefiles/BuildJdk.gmk From alan.bateman at oracle.com Tue Feb 19 11:44:54 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 19 Feb 2013 11:44:54 +0000 Subject: hg: jdk8/build/jdk: 2 new changesets Message-ID: <20130219114518.D3BD247B93@hg.openjdk.java.net> Changeset: 6f4615fd32da Author: alanb Date: 2013-02-19 11:08 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6f4615fd32da 8007097: (profiles) Build needs test to ensure that profile definitions are updated Reviewed-by: dholmes, erikj - make/tools/src/build/tools/RemoveMethods.java + make/tools/src/build/tools/classfile/RemoveMethods.java + make/tools/src/build/tools/deps/CheckDeps.java + make/tools/src/build/tools/deps/refs.allowed ! makefiles/Images.gmk ! makefiles/Tools.gmk ! makefiles/profile-rtjar-includes.txt Changeset: 033f2707ef32 Author: alanb Date: 2013-02-19 11:32 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/033f2707ef32 Merge From david.holmes at oracle.com Tue Feb 19 22:31:44 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2013 08:31:44 +1000 Subject: RFR: 8008481 Dependency analyzer needs exclusion for profile builds with JFR disabled In-Reply-To: <5123E8E2.3030409@oracle.com> References: <5123E28D.3020302@oracle.com> <5123E8E2.3030409@oracle.com> Message-ID: <5123FD50.9010501@oracle.com> Thanks Alan. cc'ing build-dev as this is technically build related and going into jdk8/build. David On 20/02/2013 7:04 AM, Alan Bateman wrote: > On 19/02/2013 20:37, David Holmes wrote: >> : >> + >> +# JFR traces even in builds with JFR disabled >> +com.oracle.jrockit.jfr.FlightRecorder: >> com.sun.management.MissionControl, compact3 >> +com.oracle.jrockit.jfr.management.FlightRecorderMBean: >> com.sun.management.MissionControl, compact3 >> + > This looks fine to okay and I know you need to get this resolved > today.It is of course a workaround to a somewhat messy issue that needs > separate follow-up. > > -Alan From david.holmes at oracle.com Tue Feb 19 22:35:21 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 19 Feb 2013 22:35:21 +0000 Subject: hg: jdk8/build/jdk: 8008481: Dependency analyzer needs exclusion for profile builds with JFR disabled Message-ID: <20130219223600.BEEAA47BB5@hg.openjdk.java.net> Changeset: 00b7535d743f Author: dholmes Date: 2013-02-19 17:32 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/00b7535d743f 8008481: Dependency analyzer needs exclusion for profile builds with JFR disabled Reviewed-by: alanb ! make/tools/src/build/tools/deps/refs.allowed From david.katleman at oracle.com Wed Feb 20 04:56:57 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 20 Feb 2013 04:56:57 +0000 Subject: hg: jdk8/build/hotspot: 35 new changesets Message-ID: <20130220045806.14C7047BC4@hg.openjdk.java.net> Changeset: 1a0174612b49 Author: amurillo Date: 2013-02-08 08:16 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1a0174612b49 8007801: new hotspot build - hs25-b19 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8d9fc28831cc Author: dcubed Date: 2013-02-06 14:31 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8d9fc28831cc 7182152: Instrumentation hot swap test incorrect monitor count Summary: Add/refine new tracing support using -XX:TraceRedefineClasses=16384. Reviewed-by: coleenp, acorn, sspitsyn ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/accessFlags.hpp Changeset: 3a88007634b0 Author: ctornqvi Date: 2013-02-08 10:42 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3a88007634b0 8007434: Write tests for 8006298 Summary: Four tests written for 8006298 Reviewed-by: mgerdin, coleenp + test/runtime/CommandLine/BooleanFlagWithInvalidValue.java + test/runtime/CommandLine/FlagWithInvalidValue.java + test/runtime/CommandLine/NonBooleanFlagWithInvalidBooleanPrefix.java + test/runtime/CommandLine/UnrecognizedVMOption.java Changeset: 758935f7c23f Author: sla Date: 2013-02-08 12:48 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/758935f7c23f 8006423: SA: NullPointerException in sun.jvm.hotspot.debugger.bsd.BsdThread.getContext(BsdThread.java:67) Summary: Do not rely on mach thread port names to identify threads from SA Reviewed-by: dholmes, minqi, rbackman ! agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp Changeset: 7194f764221c Author: sla Date: 2013-02-08 14:05 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7194f764221c Merge Changeset: 461a3adac4d1 Author: sspitsyn Date: 2013-02-08 09:14 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/461a3adac4d1 Merge ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 8bf62bd86a4e Author: zgu Date: 2013-02-08 14:49 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8bf62bd86a4e 8007791: More Restricted hs_err file permission Summary: Enforce more restricted hs_file permission Reviewed-by: acorn, dcubed, dsamersoff ! src/share/vm/utilities/vmError.cpp Changeset: 1ba5b18088a8 Author: zgu Date: 2013-02-08 14:32 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1ba5b18088a8 Merge Changeset: 41d73c9b30a8 Author: zgu Date: 2013-02-08 16:31 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/41d73c9b30a8 8006691: Remove jvm_version_info.is_kernel_jvm field Summary: Removed is_kernel_jvm from jvm_version_info as Kernel VM has been deprecated Reviewed-by: mchung, coleenp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 3f11b37f047c Author: zgu Date: 2013-02-08 13:55 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3f11b37f047c Merge Changeset: f989aff6946f Author: zgu Date: 2013-02-08 16:56 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f989aff6946f Merge Changeset: 927a311d00f9 Author: coleenp Date: 2013-02-11 14:06 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/927a311d00f9 8007320: NPG: move method annotations Summary: allocate method annotations and attach to ConstMethod if present Reviewed-by: dcubed, jiangli, sspitsyn, iklam ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/vmStructs.cpp + test/runtime/8007320/ConstMethodTest.java Changeset: 5ee2b330eacd Author: zgu Date: 2013-02-12 12:19 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5ee2b330eacd 8007950: Undo hs_file permission change Summary: Reverse hs_err file permission back to 0666, as early push was premature Reviewed-by: dsamersoff, dcubed, acorn ! src/share/vm/utilities/vmError.cpp Changeset: deb43b8a436e Author: sspitsyn Date: 2013-02-13 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/deb43b8a436e Merge Changeset: bce1ac447f6b Author: johnc Date: 2013-02-06 14:50 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bce1ac447f6b 7052429: G1: Avoid unnecessary scanning of humongous regions during concurrent marking Summary: Skip unnecessary scanning of bitmap for unmarked humongous objects/regions. Reviewed-by: jwilhelm, johnc Contributed-by: Tao Mao ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/runtime/globals.hpp Changeset: f64ffbf81af5 Author: jwilhelm Date: 2013-02-07 15:51 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f64ffbf81af5 8006432: Ratio flags should be unsigned Summary: Flags changed to be of uintx type Reviewed-by: johnc, tamao ! src/cpu/zero/vm/shark_globals_zero.hpp ! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5d8325eb8240 Author: brutisso Date: 2013-02-07 22:04 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5d8325eb8240 Merge ! src/share/vm/runtime/thread.cpp Changeset: 9425ba04792d Author: brutisso Date: 2013-02-07 18:40 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9425ba04792d Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make ! src/share/vm/runtime/arguments.cpp - test/runtime/7158988/TestFieldMonitor.sh Changeset: ad747ee9d0b1 Author: brutisso Date: 2013-02-10 21:15 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ad747ee9d0b1 8002144: G1: large number of evacuation failures may lead to large c heap memory usage Summary: Use Stack<> instead of GrowableArray to keep track of preserved marks. Also reviewed by vitalyd at gmail.com. Reviewed-by: johnc, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 5e401ef52ec0 Author: johnc Date: 2013-02-11 15:24 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5e401ef52ec0 8007772: G1: assert(!hr->isHumongous() || mr.start() == hr->bottom()) failed: the start of HeapRegion and MemRegion should be consistent for humongous regions Summary: In do_marking_step(), we should always give up current region after scanning the object, if the region is humongous. Reviewed-by: brutisso, jwilhelm, tamao ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: a83cd101fd62 Author: jmasa Date: 2013-01-23 19:08 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a83cd101fd62 8005452: NPG: Create new flags for Metaspace resizing policy Reviewed-by: johnc, jwilhelm, coleenp, stefank ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: b8d5d7a6c94c Author: brutisso Date: 2013-02-14 11:01 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b8d5d7a6c94c Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp Changeset: 91a23b11d8dc Author: kvn Date: 2013-02-08 15:07 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/91a23b11d8dc 8007708: compiler/6855215 assert(VM_Version::supports_sse4_2()) Summary: Added missing UseSSE42 check. Also added missing avx2 assert for vpermq instruction. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp Changeset: 309460dcedf7 Author: morris Date: 2013-02-08 15:39 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/309460dcedf7 8006851: When TieredCompilation is set, max code cache should be bumped to 256mb Summary: Set ReservedCodeCacheSize to (default value)*5 when TieredCompilation is on. Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp Changeset: 2c673161698a Author: drchase Date: 2013-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2c673161698a 8007402: Code cleanup to remove Parfait false positive Summary: add array access range check Reviewed-by: kvn ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp Changeset: 64d2a0a39954 Author: kmo Date: 2013-02-10 22:35 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/64d2a0a39954 8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag Summary: make sure all diagnostic and experimental flag kinds are checked in Flag::is_unlocked() Reviewed-by: kvn ! src/share/vm/runtime/globals.cpp Changeset: a9c29dfc7d73 Author: morris Date: 2013-02-11 10:38 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a9c29dfc7d73 8003251: ARM: move MacroAssembler into separate file Summary: moved MacroAssembler into separate file Reviewed-by: twisti, kvn, dlong ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp Changeset: 1e5e28bac299 Author: morris Date: 2013-02-11 14:47 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1e5e28bac299 8003252: PPC: move MacroAssembler into separate file Summary: moved MacroAssembler into separate file Reviewed-by: twisti, kvn, dlong ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp Changeset: 8b3da8d14c93 Author: roland Date: 2013-02-12 12:56 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8b3da8d14c93 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob Summary: Add support for expensive nodes. Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/subnode.hpp Changeset: c703f9c4b025 Author: kmo Date: 2013-02-12 07:39 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c703f9c4b025 8002169: TEST_BUG: compiler/7009359/Test7009359.java sometimes times out Summary: make the test less prone to timeout by reducing the amount of iteration and allowing main to be compiled Reviewed-by: jrose ! test/compiler/7009359/Test7009359.java Changeset: aaad39923cdb Author: kmo Date: 2013-02-12 14:33 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/aaad39923cdb Merge Changeset: 12e01444ca2d Author: iignatyev Date: 2013-02-13 08:29 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/12e01444ca2d 8006683: Add WhiteBox API to testing of compiler Reviewed-by: kvn, vlivanov ! src/share/tools/whitebox/sun/hotspot/WhiteBox.java ! src/share/vm/prims/wbtestmethods/parserTests.hpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/prims/whitebox.hpp + test/compiler/whitebox/CompilerWhiteBoxTest.java + test/compiler/whitebox/DeoptimizeAllTest.java + test/compiler/whitebox/DeoptimizeMethodTest.java + test/compiler/whitebox/IsMethodCompilableTest.java + test/compiler/whitebox/MakeMethodNotCompilableTest.java + test/compiler/whitebox/SetDontInlineMethodTest.java Changeset: 1cdf241a4b26 Author: vlivanov Date: 2013-02-14 05:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1cdf241a4b26 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 9f19f4a7d48a Author: amurillo Date: 2013-02-15 13:27 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9f19f4a7d48a Merge Changeset: d5e12e7d2f71 Author: amurillo Date: 2013-02-15 13:27 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d5e12e7d2f71 Added tag hs25-b19 for changeset 9f19f4a7d48a ! .hgtags From erik.joelsson at oracle.com Wed Feb 20 13:52:00 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Feb 2013 14:52:00 +0100 Subject: Review Request: 8007903: 8005583's changes to make/install-rules.gmk need to made to jdk/make/closed/InstallWrapper.gmk Message-ID: <5124D500.5080707@oracle.com> Open part of this review. Some variable assignments in the old build defs files need to be disabled for the new build to work with unconverted closed makefiles. Should not affect the old or open build at all. http://cr.openjdk.java.net/~erikj/8007903/webrev.jdk.01/ /Erik From erik.joelsson at oracle.com Wed Feb 20 14:07:47 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Feb 2013 15:07:47 +0100 Subject: Review Request: 8007387: "sed: RE error: illegal byte sequence" when building images on Mac Message-ID: <5124D8B3.7020506@oracle.com> Small fix, adding LC_ALL=C before a sed statement. At least on mac, this could cause the build to fail if you had a different locale setting. http://cr.openjdk.java.net/~erikj/8007387/webrev.jdk.01/ /Erik From erik.joelsson at oracle.com Wed Feb 20 14:20:52 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Feb 2013 15:20:52 +0100 Subject: Review Request: 8006828: "SKIP_BOOT_CYCLE=false" must work in new building infrastructure Message-ID: <5124DBC4.5050906@oracle.com> Adding check for SKIP_BOOT_CYCLE=false in Jprt.gmk which adds the target bootcycle-images. Also fixing an issue with bootcycle-images target that prevented them from creating images. http://cr.openjdk.java.net/~erikj/8006828/webrev.root.01/ /Erik From Alan.Bateman at oracle.com Wed Feb 20 14:44:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Feb 2013 14:44:20 +0000 Subject: Review Request: 8006828: "SKIP_BOOT_CYCLE=false" must work in new building infrastructure In-Reply-To: <5124DBC4.5050906@oracle.com> References: <5124DBC4.5050906@oracle.com> Message-ID: <5124E144.6060004@oracle.com> On 20/02/2013 14:20, Erik Joelsson wrote: > Adding check for SKIP_BOOT_CYCLE=false in Jprt.gmk which adds the > target bootcycle-images. Also fixing an issue with bootcycle-images > target that prevented them from creating images. > > http://cr.openjdk.java.net/~erikj/8006828/webrev.root.01/ > > /Erik This looks good to me (and important to be able to easily enable this via a -buildenv). -Alan From erik.joelsson at oracle.com Wed Feb 20 14:52:44 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Feb 2013 15:52:44 +0100 Subject: Review Request: 8008451: Make mac builds on 10.8 work on 10.7 In-Reply-To: <511E0491.7070508@oracle.com> References: <511D0FCD.4020803@oracle.com> <93A5D67B-22E9-4EB7-980E-3C8B3646DE6B@oracle.com> <511DF527.4080208@oracle.com> <511E0491.7070508@oracle.com> Message-ID: <5124E33C.3070903@oracle.com> I was wrong, just setting the macros below did not generate 10.7 compatible bits when built on 10.8. Since I already pushed the old solution (except for hotspot), I created a new bug. Here is a new set of patches, combining -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 and -mmacosx-version-min=10.7.0 and also setting the latter on the link command line. This combination both generates compatible binaries and treats newer API calls as errors, all verified. Sine the two parameters take their argument in different formats, the handling of defaults is a bit more complicated. The variable being sent around and that you can override on the command line is now MACOSX_VERSION_MIN=10.7.0, matching the parameter to the compiler/linker. It would be good if someone from hotspot could review the hotspot changes. http://cr.openjdk.java.net/~erikj/8008451/webrev.hotspot.01/ http://cr.openjdk.java.net/~erikj/8008451/webrev.root.01/ http://cr.openjdk.java.net/~erikj/8008451/webrev.jdk.01/ /Erik On 2013-02-15 10:49, Erik Joelsson wrote: > > > On 2013-02-15 09:43, Erik Joelsson wrote: >> >> On 2013-02-14 18:04, David DeHaven wrote: >>>> Here are a series of patches that adds the following to all native >>>> compile lines on macosx: >>>> >>>> -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 >>>> -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 >>> I know I'm not a reviewer, but I have an opinion anyways :) >>> >>> Using "-mmacosx-version-min=10.7" seems more appropriate for the >>> latter, this is passed to the linker as well which I believe sets >>> version information in the Mach-O headers (in the form of a load >>> command) to prevent it from being loaded on older systems. The >>> MIN_REQUIRED macro is set to a value that matches what's passed to >>> the -mmacosx-version-min argument, so it doesn't need to be provided. >>> >>> >> The effect of the -mmacosx-version-min=10.7 when sent to the linker >> is to make any calls to newer APIs "softlinked". This means the >> library will still load fine on the older OS, but the application is >> responsible for only actually making the newer calls if they are >> available. This is a good feature if you knowingly want to support >> multiple versions of the OS and still use features in the newer OS >> when available. I do not believe we have the need for that and if we >> ever do, then these parameters will need to change. >> > It's true -mmacosx-version-min= also sets the macro > MAC_OS_X_VERSION_MIN_REQUIRED=, but I see no gain in changing just one > of them to something else just because it works. The format of the > parameter is also different (10.7 vs 1070) which would require us to > add logic for converting between the two. > > /Erik From daniel.daugherty at oracle.com Wed Feb 20 15:00:31 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Feb 2013 08:00:31 -0700 Subject: Review Request: 8008451: Make mac builds on 10.8 work on 10.7 In-Reply-To: <5124E33C.3070903@oracle.com> References: <511D0FCD.4020803@oracle.com> <93A5D67B-22E9-4EB7-980E-3C8B3646DE6B@oracle.com> <511DF527.4080208@oracle.com> <511E0491.7070508@oracle.com> <5124E33C.3070903@oracle.com> Message-ID: <5124E50F.2060804@oracle.com> Widening the NotSpot net from just Runtime to all of HotSpot... Dan On 2/20/13 7:52 AM, Erik Joelsson wrote: > I was wrong, just setting the macros below did not generate 10.7 > compatible bits when built on 10.8. Since I already pushed the old > solution (except for hotspot), I created a new bug. Here is a new set > of patches, combining -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 and > -mmacosx-version-min=10.7.0 and also setting the latter on the link > command line. This combination both generates compatible binaries and > treats newer API calls as errors, all verified. > > Sine the two parameters take their argument in different formats, the > handling of defaults is a bit more complicated. The variable being > sent around and that you can override on the command line is now > MACOSX_VERSION_MIN=10.7.0, matching the parameter to the compiler/linker. > > It would be good if someone from hotspot could review the hotspot > changes. > > http://cr.openjdk.java.net/~erikj/8008451/webrev.hotspot.01/ > http://cr.openjdk.java.net/~erikj/8008451/webrev.root.01/ > http://cr.openjdk.java.net/~erikj/8008451/webrev.jdk.01/ > > /Erik > > On 2013-02-15 10:49, Erik Joelsson wrote: >> >> >> On 2013-02-15 09:43, Erik Joelsson wrote: >>> >>> On 2013-02-14 18:04, David DeHaven wrote: >>>>> Here are a series of patches that adds the following to all native >>>>> compile lines on macosx: >>>>> >>>>> -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 >>>>> -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 >>>> I know I'm not a reviewer, but I have an opinion anyways :) >>>> >>>> Using "-mmacosx-version-min=10.7" seems more appropriate for the >>>> latter, this is passed to the linker as well which I believe sets >>>> version information in the Mach-O headers (in the form of a load >>>> command) to prevent it from being loaded on older systems. The >>>> MIN_REQUIRED macro is set to a value that matches what's passed to >>>> the -mmacosx-version-min argument, so it doesn't need to be provided. >>>> >>>> >>> The effect of the -mmacosx-version-min=10.7 when sent to the linker >>> is to make any calls to newer APIs "softlinked". This means the >>> library will still load fine on the older OS, but the application is >>> responsible for only actually making the newer calls if they are >>> available. This is a good feature if you knowingly want to support >>> multiple versions of the OS and still use features in the newer OS >>> when available. I do not believe we have the need for that and if we >>> ever do, then these parameters will need to change. >>> >> It's true -mmacosx-version-min= also sets the macro >> MAC_OS_X_VERSION_MIN_REQUIRED=, but I see no gain in changing just >> one of them to something else just because it works. The format of >> the parameter is also different (10.7 vs 1070) which would require us >> to add logic for converting between the two. >> >> /Erik From kelly.ohair at oracle.com Wed Feb 20 16:01:34 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 20 Feb 2013 08:01:34 -0800 Subject: Review Request: 8008451: Make mac builds on 10.8 work on 10.7 In-Reply-To: <5124E33C.3070903@oracle.com> References: <511D0FCD.4020803@oracle.com> <93A5D67B-22E9-4EB7-980E-3C8B3646DE6B@oracle.com> <511DF527.4080208@oracle.com> <511E0491.7070508@oracle.com> <5124E33C.3070903@oracle.com> Message-ID: Looks good to me. And thank you for doing the verification. -kto On Feb 20, 2013, at 6:52 AM, Erik Joelsson wrote: > I was wrong, just setting the macros below did not generate 10.7 compatible bits when built on 10.8. Since I already pushed the old solution (except for hotspot), I created a new bug. Here is a new set of patches, combining -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 and -mmacosx-version-min=10.7.0 and also setting the latter on the link command line. This combination both generates compatible binaries and treats newer API calls as errors, all verified. > > Sine the two parameters take their argument in different formats, the handling of defaults is a bit more complicated. The variable being sent around and that you can override on the command line is now MACOSX_VERSION_MIN=10.7.0, matching the parameter to the compiler/linker. > > It would be good if someone from hotspot could review the hotspot changes. > > http://cr.openjdk.java.net/~erikj/8008451/webrev.hotspot.01/ > http://cr.openjdk.java.net/~erikj/8008451/webrev.root.01/ > http://cr.openjdk.java.net/~erikj/8008451/webrev.jdk.01/ > > /Erik > > On 2013-02-15 10:49, Erik Joelsson wrote: >> >> >> On 2013-02-15 09:43, Erik Joelsson wrote: >>> >>> On 2013-02-14 18:04, David DeHaven wrote: >>>>> Here are a series of patches that adds the following to all native compile lines on macosx: >>>>> >>>>> -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 >>>> I know I'm not a reviewer, but I have an opinion anyways :) >>>> >>>> Using "-mmacosx-version-min=10.7" seems more appropriate for the latter, this is passed to the linker as well which I believe sets version information in the Mach-O headers (in the form of a load command) to prevent it from being loaded on older systems. The MIN_REQUIRED macro is set to a value that matches what's passed to the -mmacosx-version-min argument, so it doesn't need to be provided. >>>> >>>> >>> The effect of the -mmacosx-version-min=10.7 when sent to the linker is to make any calls to newer APIs "softlinked". This means the library will still load fine on the older OS, but the application is responsible for only actually making the newer calls if they are available. This is a good feature if you knowingly want to support multiple versions of the OS and still use features in the newer OS when available. I do not believe we have the need for that and if we ever do, then these parameters will need to change. >>> >> It's true -mmacosx-version-min= also sets the macro MAC_OS_X_VERSION_MIN_REQUIRED=, but I see no gain in changing just one of them to something else just because it works. The format of the parameter is also different (10.7 vs 1070) which would require us to add logic for converting between the two. >> >> /Erik From david.dehaven at oracle.com Wed Feb 20 18:49:35 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 20 Feb 2013 10:49:35 -0800 Subject: Review Request: 8008451: Make mac builds on 10.8 work on 10.7 In-Reply-To: <5124E50F.2060804@oracle.com> References: <511D0FCD.4020803@oracle.com> <93A5D67B-22E9-4EB7-980E-3C8B3646DE6B@oracle.com> <511DF527.4080208@oracle.com> <511E0491.7070508@oracle.com> <5124E33C.3070903@oracle.com> <5124E50F.2060804@oracle.com> Message-ID: <308D7F70-D4D9-43B1-B50F-A5A1064201E9@oracle.com> >> I was wrong, just setting the macros below did not generate 10.7 compatible bits when built on 10.8. Since I already pushed the old solution (except for hotspot), I created a new bug. Here is a new set of patches, combining -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 and -mmacosx-version-min=10.7.0 and also setting the latter on the link command line. This combination both generates compatible binaries and treats newer API calls as errors, all verified. >> >> Sine the two parameters take their argument in different formats, the handling of defaults is a bit more complicated. The variable being sent around and that you can override on the command line is now MACOSX_VERSION_MIN=10.7.0, matching the parameter to the compiler/linker. >> >> It would be good if someone from hotspot could review the hotspot changes. >> >> http://cr.openjdk.java.net/~erikj/8008451/webrev.hotspot.01/ >> http://cr.openjdk.java.net/~erikj/8008451/webrev.root.01/ >> http://cr.openjdk.java.net/~erikj/8008451/webrev.jdk.01/ Looks good to me! -DrD- From John.Coomes at oracle.com Wed Feb 20 19:53:22 2013 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 20 Feb 2013 11:53:22 -0800 Subject: Review Request: 8008451: Make mac builds on 10.8 work on 10.7 In-Reply-To: <5124E33C.3070903@oracle.com> References: <511D0FCD.4020803@oracle.com> <93A5D67B-22E9-4EB7-980E-3C8B3646DE6B@oracle.com> <511DF527.4080208@oracle.com> <511E0491.7070508@oracle.com> <5124E33C.3070903@oracle.com> Message-ID: <20773.10674.494494.347984@oracle.com> Erik Joelsson (erik.joelsson at oracle.com) wrote: > I was wrong, just setting the macros below did not generate 10.7 > compatible bits when built on 10.8. Since I already pushed the old > solution (except for hotspot), I created a new bug. Here is a new set of > patches, combining -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 and > -mmacosx-version-min=10.7.0 and also setting the latter on the link > command line. This combination both generates compatible binaries and > treats newer API calls as errors, all verified. > > Sine the two parameters take their argument in different formats, the > handling of defaults is a bit more complicated. The variable being sent > around and that you can override on the command line is now > MACOSX_VERSION_MIN=10.7.0, matching the parameter to the compiler/linker. > > It would be good if someone from hotspot could review the hotspot changes. > > http://cr.openjdk.java.net/~erikj/8008451/webrev.hotspot.01/ The hotspot changes look good to me. -John > http://cr.openjdk.java.net/~erikj/8008451/webrev.root.01/ > http://cr.openjdk.java.net/~erikj/8008451/webrev.jdk.01/ > > /Erik > > On 2013-02-15 10:49, Erik Joelsson wrote: > > > > > > On 2013-02-15 09:43, Erik Joelsson wrote: > >> > >> On 2013-02-14 18:04, David DeHaven wrote: > >>>> Here are a series of patches that adds the following to all native > >>>> compile lines on macosx: > >>>> > >>>> -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 > >>>> -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 > >>> I know I'm not a reviewer, but I have an opinion anyways :) > >>> > >>> Using "-mmacosx-version-min=10.7" seems more appropriate for the > >>> latter, this is passed to the linker as well which I believe sets > >>> version information in the Mach-O headers (in the form of a load > >>> command) to prevent it from being loaded on older systems. The > >>> MIN_REQUIRED macro is set to a value that matches what's passed to > >>> the -mmacosx-version-min argument, so it doesn't need to be provided. > >>> > >>> > >> The effect of the -mmacosx-version-min=10.7 when sent to the linker > >> is to make any calls to newer APIs "softlinked". This means the > >> library will still load fine on the older OS, but the application is > >> responsible for only actually making the newer calls if they are > >> available. This is a good feature if you knowingly want to support > >> multiple versions of the OS and still use features in the newer OS > >> when available. I do not believe we have the need for that and if we > >> ever do, then these parameters will need to change. > >> > > It's true -mmacosx-version-min= also sets the macro > > MAC_OS_X_VERSION_MIN_REQUIRED=, but I see no gain in changing just one > > of them to something else just because it works. The format of the > > parameter is also different (10.7 vs 1070) which would require us to > > add logic for converting between the two. > > > > /Erik From tim.bell at oracle.com Wed Feb 20 21:45:02 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 20 Feb 2013 13:45:02 -0800 Subject: Review Request: 8007903: 8005583's changes to make/install-rules.gmk need to made to jdk/make/closed/InstallWrapper.gmk In-Reply-To: <5124D500.5080707@oracle.com> References: <5124D500.5080707@oracle.com> Message-ID: <512543DE.9010001@oracle.com> Hi Erik: > Open part of this review. Some variable assignments in the old build > defs files need to be disabled for the new build to work with > unconverted closed makefiles. Should not affect the old or open build > at all. > > http://cr.openjdk.java.net/~erikj/8007903/webrev.jdk.01/ Looks good. Tim From tim.bell at oracle.com Wed Feb 20 21:57:35 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 20 Feb 2013 13:57:35 -0800 Subject: Review Request: 8007387: "sed: RE error: illegal byte sequence" when building images on Mac In-Reply-To: <5124D8B3.7020506@oracle.com> References: <5124D8B3.7020506@oracle.com> Message-ID: <512546CF.8040906@oracle.com> Hi Erik: > Small fix, adding LC_ALL=C before a sed statement. At least on mac, > this could cause the build to fail if you had a different locale setting. > > http://cr.openjdk.java.net/~erikj/8007387/webrev.jdk.01/ Looks good. Tim From tim.bell at oracle.com Wed Feb 20 22:00:01 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 20 Feb 2013 14:00:01 -0800 Subject: Review Request: 8006828: "SKIP_BOOT_CYCLE=false" must work in new building infrastructure In-Reply-To: <5124E144.6060004@oracle.com> References: <5124DBC4.5050906@oracle.com> <5124E144.6060004@oracle.com> Message-ID: <51254761.9080909@oracle.com> On 02/20/13 06:44, Alan Bateman wrote: > On 20/02/2013 14:20, Erik Joelsson wrote: >> Adding check for SKIP_BOOT_CYCLE=false in Jprt.gmk which adds the >> target bootcycle-images. Also fixing an issue with bootcycle-images >> target that prevented them from creating images. >> >> http://cr.openjdk.java.net/~erikj/8006828/webrev.root.01/ >> >> /Erik > This looks good to me (and important to be able to easily enable this > via a -buildenv). > > -Alan Looks good to me as well. Tim From alexandr.scherbatiy at oracle.com Thu Feb 21 09:31:36 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 21 Feb 2013 13:31:36 +0400 Subject: OpenJDK rebuilding on windows takes a long time In-Reply-To: <511E51AA.6000109@oracle.com> References: <5114ED06.1040802@oracle.com> <51150FB3.7@oracle.com> <5118D476.6030203@oracle.com> <5118DE08.4080709@oracle.com> <511B7B50.3070402@oracle.com> <511E51AA.6000109@oracle.com> Message-ID: <5125E978.6010004@oracle.com> I have created the issue: 8008641 JDK 8 rebuilding time regression on Windows Thanks, Alexandr. On 2/15/2013 7:18 PM, Alexander Scherbatiy wrote: > On 2/13/2013 8:45 PM, Kelly O'Hair wrote: >> You are pointing at the fastdebug jdk as your boot jdk, why? >> >> The official boot jdk for jdk8 is jdk7u7 we cannot guarantee anything >> else will work, although it should, >> when tracking down issues like this, you need to narrow down all the >> possible differences. >> >> I have no idea at this time what the 'sync state' is with the awt >> team forest. >> My recommendation would be to clone the official jdk8/jdk8 forest, >> which can be assumed to work since >> RE should have built it, or any integrator pushing changes into it >> should have built it. >> Create 2 forests of so you can do separate experiments on each. >> >> Then do the build from the root with a 7u7 jdk in your PATH (no need >> for the --with-boot-jdk option). >> Do a build without --enable-sjavac on one forest, then with it on the >> other. > > I made the proposed experiment. My goal is to build debug > version of JDK that does not take a long time to rebuild. > > I put 1.7.0_07-b32 to PATH variable so > ------------------------------------------------------------------- > $ java -version > java version "1.7.0_07" > Java(TM) SE Runtime Environment (build 1.7.0_07-b32) > Java HotSpot(TM) Client VM (build 23.3-b01, mixed mode) > ------------------------------------------------------------------ > > I used http://hg.openjdk.java.net/jdk8/jdk8 repository. > Each time I used the clean repository. > > 1) Build only debug version > configure-arguments: --with-target-bits=32 --enable-debug > > ----- Build times ------- > Start 2013-02-15 16:22:41 > End 2013-02-15 16:40:01 > 00:00:45 corba > 00:04:54 hotspot > 00:00:38 jaxp > 00:00:56 jaxws > 00:09:18 jdk > 00:00:41 langtools > 00:17:20 TOTAL > ------------------------- > > Build is successful. > > 2a) Build debug version with sjava (the same JDK in PATH, the same > repository) > configure-arguments: --with-target-bits=32 --enable-debug > --enable-sjavac > > 100 errors > 3 warnings > make[1]: *** > [/cygdrive/c/Sun/OpenJDK/utils/config/jdk8-sjavac/build/windows-x86-normal-server-fastdebug/jaxws/jaxws_classes/javac_state] > Error 127 > make[1]: *** Waiting for unfinished jobs.... > make: *** [jaxws-only] Error 2 > > See the attached out.txt and out.txt files in the attached zip. > > 2b) Build debug version with sjava (the same JDK in PATH, the same > repository) > configure-arguments: --with-target-bits=32 --enable-debug > --enable-sjavac > > with the suggested patch that checks "os.name" variable: > ----------------------------------------------------------- > diff --git > a/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java > b/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java > --- a/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java > +++ b/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java > @@ -255,7 +255,7 @@ > } > // Load visible sources > Set visibleSources = new HashSet(); > - boolean fix_drive_letter_case = > System.getProperty("os.name").toLowerCase().equals("windows"); > + boolean fix_drive_letter_case = > System.getProperty("os.name").toLowerCase().startsWith("windows"); > for (;;) { > String l = in.readLine(); > if (l == null) > ----------------------------------------------------------- > > Compilation fails with error: > ----------------------------------------------------------- > The system is out of resources. > Consult the following stack trace for details. > java.lang.OutOfMemoryError: Java heap space > ----------------------------------------------------------- > See the attached out_patch.txt and err_patch.txt files in the > attached zip. > > > Could you check this scenario (--with-target-bits=32 --enable-debug > --enable-sjavac) on your side? > > > Thanks, > Alexandr. > >> -kto From erik.joelsson at oracle.com Thu Feb 21 10:24:49 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 Feb 2013 11:24:49 +0100 Subject: OpenJDK rebuilding on windows takes a long time In-Reply-To: <5125E978.6010004@oracle.com> References: <5114ED06.1040802@oracle.com> <51150FB3.7@oracle.com> <5118D476.6030203@oracle.com> <5118DE08.4080709@oracle.com> <511B7B50.3070402@oracle.com> <511E51AA.6000109@oracle.com> <5125E978.6010004@oracle.com> Message-ID: <5125F5F1.6040505@oracle.com> If sjavac isn't working well for you, you could also try the workaround we put in place. Read section 5 in the user guide here: http://openjdk.java.net/projects/build-infra/guide.html /Erik On 2013-02-21 10:31, Alexander Scherbatiy wrote: > > I have created the issue: 8008641 JDK 8 rebuilding time regression > on Windows > > Thanks, > Alexandr. > > On 2/15/2013 7:18 PM, Alexander Scherbatiy wrote: >> On 2/13/2013 8:45 PM, Kelly O'Hair wrote: >>> You are pointing at the fastdebug jdk as your boot jdk, why? >>> >>> The official boot jdk for jdk8 is jdk7u7 we cannot guarantee >>> anything else will work, although it should, >>> when tracking down issues like this, you need to narrow down all the >>> possible differences. >>> >>> I have no idea at this time what the 'sync state' is with the awt >>> team forest. >>> My recommendation would be to clone the official jdk8/jdk8 forest, >>> which can be assumed to work since >>> RE should have built it, or any integrator pushing changes into it >>> should have built it. >>> Create 2 forests of so you can do separate experiments on each. >>> >>> Then do the build from the root with a 7u7 jdk in your PATH (no need >>> for the --with-boot-jdk option). >>> Do a build without --enable-sjavac on one forest, then with it on >>> the other. >> >> I made the proposed experiment. My goal is to build debug >> version of JDK that does not take a long time to rebuild. >> >> I put 1.7.0_07-b32 to PATH variable so >> ------------------------------------------------------------------- >> $ java -version >> java version "1.7.0_07" >> Java(TM) SE Runtime Environment (build 1.7.0_07-b32) >> Java HotSpot(TM) Client VM (build 23.3-b01, mixed mode) >> ------------------------------------------------------------------ >> >> I used http://hg.openjdk.java.net/jdk8/jdk8 repository. >> Each time I used the clean repository. >> >> 1) Build only debug version >> configure-arguments: --with-target-bits=32 --enable-debug >> >> ----- Build times ------- >> Start 2013-02-15 16:22:41 >> End 2013-02-15 16:40:01 >> 00:00:45 corba >> 00:04:54 hotspot >> 00:00:38 jaxp >> 00:00:56 jaxws >> 00:09:18 jdk >> 00:00:41 langtools >> 00:17:20 TOTAL >> ------------------------- >> >> Build is successful. >> >> 2a) Build debug version with sjava (the same JDK in PATH, the same >> repository) >> configure-arguments: --with-target-bits=32 --enable-debug >> --enable-sjavac >> >> 100 errors >> 3 warnings >> make[1]: *** >> [/cygdrive/c/Sun/OpenJDK/utils/config/jdk8-sjavac/build/windows-x86-normal-server-fastdebug/jaxws/jaxws_classes/javac_state] >> Error 127 >> make[1]: *** Waiting for unfinished jobs.... >> make: *** [jaxws-only] Error 2 >> >> See the attached out.txt and out.txt files in the attached zip. >> >> 2b) Build debug version with sjava (the same JDK in PATH, the same >> repository) >> configure-arguments: --with-target-bits=32 --enable-debug >> --enable-sjavac >> >> with the suggested patch that checks "os.name" variable: >> ----------------------------------------------------------- >> diff --git >> a/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java >> b/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java >> --- a/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java >> +++ b/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java >> @@ -255,7 +255,7 @@ >> } >> // Load visible sources >> Set visibleSources = new HashSet(); >> - boolean fix_drive_letter_case = >> System.getProperty("os.name").toLowerCase().equals("windows"); >> + boolean fix_drive_letter_case = >> System.getProperty("os.name").toLowerCase().startsWith("windows"); >> for (;;) { >> String l = in.readLine(); >> if (l == null) >> ----------------------------------------------------------- >> >> Compilation fails with error: >> ----------------------------------------------------------- >> The system is out of resources. >> Consult the following stack trace for details. >> java.lang.OutOfMemoryError: Java heap space >> ----------------------------------------------------------- >> See the attached out_patch.txt and err_patch.txt files in the >> attached zip. >> >> >> Could you check this scenario (--with-target-bits=32 --enable-debug >> --enable-sjavac) on your side? >> >> >> Thanks, >> Alexandr. >> >>> -kto > From alexandr.scherbatiy at oracle.com Thu Feb 21 10:45:21 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 21 Feb 2013 14:45:21 +0400 Subject: OpenJDK rebuilding on windows takes a long time In-Reply-To: <5125F5F1.6040505@oracle.com> References: <5114ED06.1040802@oracle.com> <51150FB3.7@oracle.com> <5118D476.6030203@oracle.com> <5118DE08.4080709@oracle.com> <511B7B50.3070402@oracle.com> <511E51AA.6000109@oracle.com> <5125E978.6010004@oracle.com> <5125F5F1.6040505@oracle.com> Message-ID: <5125FAC0.5040205@oracle.com> On 2/21/2013 2:24 PM, Erik Joelsson wrote: > If sjavac isn't working well for you, you could also try the > workaround we put in place. Read section 5 in the user guide here: > > http://openjdk.java.net/projects/build-infra/guide.html I tried to use the filter make jdk-only JDK_FILTER="javax/swing" and now JDK building takes about a minute. Thank you, it helps. > > /Erik > > On 2013-02-21 10:31, Alexander Scherbatiy wrote: >> >> I have created the issue: 8008641 JDK 8 rebuilding time regression >> on Windows >> >> Thanks, >> Alexandr. >> >> On 2/15/2013 7:18 PM, Alexander Scherbatiy wrote: >>> On 2/13/2013 8:45 PM, Kelly O'Hair wrote: >>>> You are pointing at the fastdebug jdk as your boot jdk, why? >>>> >>>> The official boot jdk for jdk8 is jdk7u7 we cannot guarantee >>>> anything else will work, although it should, >>>> when tracking down issues like this, you need to narrow down all >>>> the possible differences. >>>> >>>> I have no idea at this time what the 'sync state' is with the awt >>>> team forest. >>>> My recommendation would be to clone the official jdk8/jdk8 forest, >>>> which can be assumed to work since >>>> RE should have built it, or any integrator pushing changes into it >>>> should have built it. >>>> Create 2 forests of so you can do separate experiments on each. >>>> >>>> Then do the build from the root with a 7u7 jdk in your PATH (no >>>> need for the --with-boot-jdk option). >>>> Do a build without --enable-sjavac on one forest, then with it on >>>> the other. >>> >>> I made the proposed experiment. My goal is to build debug >>> version of JDK that does not take a long time to rebuild. >>> >>> I put 1.7.0_07-b32 to PATH variable so >>> ------------------------------------------------------------------- >>> $ java -version >>> java version "1.7.0_07" >>> Java(TM) SE Runtime Environment (build 1.7.0_07-b32) >>> Java HotSpot(TM) Client VM (build 23.3-b01, mixed mode) >>> ------------------------------------------------------------------ >>> >>> I used http://hg.openjdk.java.net/jdk8/jdk8 repository. >>> Each time I used the clean repository. >>> >>> 1) Build only debug version >>> configure-arguments: --with-target-bits=32 --enable-debug >>> >>> ----- Build times ------- >>> Start 2013-02-15 16:22:41 >>> End 2013-02-15 16:40:01 >>> 00:00:45 corba >>> 00:04:54 hotspot >>> 00:00:38 jaxp >>> 00:00:56 jaxws >>> 00:09:18 jdk >>> 00:00:41 langtools >>> 00:17:20 TOTAL >>> ------------------------- >>> >>> Build is successful. >>> >>> 2a) Build debug version with sjava (the same JDK in PATH, the same >>> repository) >>> configure-arguments: --with-target-bits=32 --enable-debug >>> --enable-sjavac >>> >>> 100 errors >>> 3 warnings >>> make[1]: *** >>> [/cygdrive/c/Sun/OpenJDK/utils/config/jdk8-sjavac/build/windows-x86-normal-server-fastdebug/jaxws/jaxws_classes/javac_state] >>> Error 127 >>> make[1]: *** Waiting for unfinished jobs.... >>> make: *** [jaxws-only] Error 2 >>> >>> See the attached out.txt and out.txt files in the attached zip. >>> >>> 2b) Build debug version with sjava (the same JDK in PATH, the same >>> repository) >>> configure-arguments: --with-target-bits=32 --enable-debug >>> --enable-sjavac >>> >>> with the suggested patch that checks "os.name" variable: >>> ----------------------------------------------------------- >>> diff --git >>> a/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java >>> b/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java >>> --- a/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java >>> +++ b/src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java >>> @@ -255,7 +255,7 @@ >>> } >>> // Load visible sources >>> Set visibleSources = new HashSet(); >>> - boolean fix_drive_letter_case = >>> System.getProperty("os.name").toLowerCase().equals("windows"); >>> + boolean fix_drive_letter_case = >>> System.getProperty("os.name").toLowerCase().startsWith("windows"); >>> for (;;) { >>> String l = in.readLine(); >>> if (l == null) >>> ----------------------------------------------------------- >>> >>> Compilation fails with error: >>> ----------------------------------------------------------- >>> The system is out of resources. >>> Consult the following stack trace for details. >>> java.lang.OutOfMemoryError: Java heap space >>> ----------------------------------------------------------- >>> See the attached out_patch.txt and err_patch.txt files in the >>> attached zip. >>> >>> >>> Could you check this scenario (--with-target-bits=32 --enable-debug >>> --enable-sjavac) on your side? >>> >>> >>> Thanks, >>> Alexandr. >>> >>>> -kto >> From erik.joelsson at oracle.com Thu Feb 21 17:08:07 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 21 Feb 2013 17:08:07 +0000 Subject: hg: jdk8/build/jdk: 3 new changesets Message-ID: <20130221170909.47A9E47C42@hg.openjdk.java.net> Changeset: 5a1ea5bbe10a Author: erikj Date: 2013-02-21 14:14 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5a1ea5bbe10a 8007387: "sed: RE error: illegal byte sequence" when building images on Mac Reviewed-by: tbell ! makefiles/Images.gmk Changeset: a287f6a0d46d Author: erikj Date: 2013-02-21 14:16 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a287f6a0d46d 8008451: Make mac builds on 10.8 work on 10.7 Reviewed-by: ohair, ddehaven ! make/common/Defs-macosx.gmk Changeset: 5d27f8702118 Author: erikj Date: 2013-02-21 14:23 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5d27f8702118 8007903: 8005583's changes to make/install-rules.gmk need to made to jdk/make/closed/InstallWrapper.gmk Reviewed-by: tbell, ohair ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-utils.gmk From erik.joelsson at oracle.com Thu Feb 21 17:07:53 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 21 Feb 2013 17:07:53 +0000 Subject: hg: jdk8/build: 8008451: Make mac builds on 10.8 work on 10.7 Message-ID: <20130221170753.E11EB47C41@hg.openjdk.java.net> Changeset: ab82853d3365 Author: erikj Date: 2013-02-21 14:16 +0100 URL: http://hg.openjdk.java.net/jdk8/build/rev/ab82853d3365 8008451: Make mac builds on 10.8 work on 10.7 Reviewed-by: ohair, ddehaven ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 From christos at zoulas.com Wed Feb 6 16:26:27 2013 From: christos at zoulas.com (Christos Zoulas) Date: Wed, 06 Feb 2013 16:26:27 -0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <51122AC8.2070400@oracle.com> from Chris Hegarty (Feb 6, 10:04am) Message-ID: <20130206162627.4080E97129@rebar.astron.com> On Feb 6, 10:04am, chris.hegarty at oracle.com (Chris Hegarty) wrote: -- Subject: Re: RFR: race with nested repos in hgforest.sh | Yes this is better, but the quotes are incorrect. It should simply be | for rc in ${tmp}/*.pid.rc ; do This will break if there is no match. christos From gerard.ziemski at oracle.com Fri Feb 8 17:48:20 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 08 Feb 2013 11:48:20 -0600 Subject: Does anyone have an Xcode project to build Hotspot? Message-ID: <51153A64.7040209@oracle.com> hi guys, I hope this is the right place to ask this question, if not please suggest where else I could ask it. Does anyone here have an Xcode project to build Hotspot? For reference, I have filed https://jbs.oracle.com/bugs/browse/JDK-8007737 to track this issue. cheers From martijnverburg at gmail.com Thu Feb 21 23:31:34 2013 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 21 Feb 2013 23:31:34 +0000 Subject: Does anyone have an Xcode project to build Hotspot? In-Reply-To: <51153A64.7040209@oracle.com> References: <51153A64.7040209@oracle.com> Message-ID: Closest thing we have is an Eclipse project I'm afraid. Cheers, Martijn On 8 February 2013 17:48, Gerard Ziemski wrote: > hi guys, > > I hope this is the right place to ask this question, if not please suggest > where else I could ask it. > > Does anyone here have an Xcode project to build Hotspot? > > For reference, I have filed https://jbs.oracle.com/bugs/browse/JDK-8007737 > to track this issue. > > > cheers From david.holmes at oracle.com Fri Feb 22 04:10:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Feb 2013 14:10:23 +1000 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: References: Message-ID: <5126EFAF.5000101@oracle.com> Hi Christian, cc'ing build-dev On 22/02/2013 12:40 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8006965 > > 8006965: test_gamma should run with import JDK > Reviewed-by: > > Right now test_gamma runs with the boot JDK which is JDK n-1 (where > JDK n is the version we are actually compiling for). This setup is > unsupported and thus should not be done during HotSpot builds. > > The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when > running test_gamma. First, the simplest change seems to me to just to do: ! MAKE_ARGS += JAVA_HOME=$(JDK_IMPORT_PATH) and not need to change anything in buildtree.make. But this forces everyone outside of Oracle (and some inside) to have to set ALT_JDK_IMPORT_PATH explicitly otherwise they get: JDK_IMPORT_PATH=$(SLASH_JAVA)/re/j2se/$(JDK_VERSION)/promoted/latest/binaries/$(PLATFORM) And the boot JDK is only JDK n-1 for our official builds - people can use whatever boot JDK works for them including latest JDK. I see the problem you want to fix, and I know why you've hit it, but this doesn't seem like a general solution. I don't know what to suggest. > make/bsd/makefiles/buildtree.make > make/defs.make Why did you add: MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) ? David ----- > make/linux/makefiles/buildtree.make > make/solaris/makefiles/buildtree.make > From christian.thalinger at oracle.com Fri Feb 22 16:47:54 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Feb 2013 08:47:54 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <5126EFAF.5000101@oracle.com> References: <5126EFAF.5000101@oracle.com> Message-ID: On Feb 21, 2013, at 8:10 PM, David Holmes wrote: > Hi Christian, > > cc'ing build-dev > > On 22/02/2013 12:40 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8006965 >> >> 8006965: test_gamma should run with import JDK >> Reviewed-by: >> >> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >> JDK n is the version we are actually compiling for). This setup is >> unsupported and thus should not be done during HotSpot builds. >> >> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >> running test_gamma. > > First, the simplest change seems to me to just to do: > > ! MAKE_ARGS += JAVA_HOME=$(JDK_IMPORT_PATH) > > and not need to change anything in buildtree.make. Maybe. But the conditional setting of JAVA_HOME in env.sh is a problem. > > But this forces everyone outside of Oracle (and some inside) to have to set ALT_JDK_IMPORT_PATH explicitly otherwise they get: > > JDK_IMPORT_PATH=$(SLASH_JAVA)/re/j2se/$(JDK_VERSION)/promoted/latest/binaries/$(PLATFORM) That should be set by the OpenJDK build. And people who are only building hotspot are probably setting this anyway (and are special). > > And the boot JDK is only JDK n-1 for our official builds - people can use whatever boot JDK works for them including latest JDK. Right. They can use whatever boot JDK they want but not import. > > I see the problem you want to fix, and I know why you've hit it, but this doesn't seem like a general solution. I don't know what to suggest. > >> make/bsd/makefiles/buildtree.make >> make/defs.make > > Why did you add: > > MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) > > ? Because JAVA_HOME was overwritten by ABS_BOOTDIR which looks completely wrong to me (and caused a problem with a version of the patch that still had the conditional setting of JAVA_HOME). -- Chris > > David > ----- > >> make/linux/makefiles/buildtree.make >> make/solaris/makefiles/buildtree.make >> From martinrb at google.com Fri Feb 22 22:03:23 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 Feb 2013 14:03:23 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so Message-ID: Hi Alan, Xueming, build-ers, I'd like you to do a code review. I've finally figured out why fastdebug jdk occasionally gives InternalError in the zip code. Exception in thread "main" java.lang.InternalError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.(Inflater.java:101) at java.util.zip.ZipFile.getInflater(ZipFile.java:448) It's because: - jdk changed structure size of z_stream struct - making jdk zlib incompatible with stock zlib - as a result of which, it is imperative to keep jdk zlib sequestered from system zlib - so need to not export zlib symbols from libzip.so - so need to tell makefiles to use linker script unconditionally http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ From xueming.shen at oracle.com Fri Feb 22 22:15:48 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 22 Feb 2013 14:15:48 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: Message-ID: <5127EE14.5010608@oracle.com> Here is the bugid you will need. 8008759: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so On 02/22/2013 02:03 PM, Martin Buchholz wrote: > Hi Alan, Xueming, build-ers, > > I'd like you to do a code review. > > I've finally figured out why fastdebug jdk occasionally gives InternalError in the zip code. > > Exception in thread "main" java.lang.InternalError > at java.util.zip.Inflater.init(Native Method) > at java.util.zip.Inflater.(Inflater.java:101) > at java.util.zip.ZipFile.getInflater(ZipFile.java:448) > > It's because: > - jdk changed structure size of z_stream struct > - making jdk zlib incompatible with stock zlib > - as a result of which, it is imperative to keep jdk zlib sequestered from system zlib > - so need to not export zlib symbols from libzip.so > - so need to tell makefiles to use linker script unconditionally > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ > From martinrb at google.com Fri Feb 22 22:29:36 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 Feb 2013 14:29:36 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: <5127EE14.5010608@oracle.com> References: <5127EE14.5010608@oracle.com> Message-ID: On Fri, Feb 22, 2013 at 2:15 PM, Xueming Shen wrote: > ** > Here is the bugid you will need. > > 8008759: Do not let internal JDK zlib symbols leak out of fastdebug > libzip.so > > Thanks! webrev updated. From martinrb at google.com Sat Feb 23 01:36:17 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 Feb 2013 17:36:17 -0800 Subject: "j2sdk-image" and new build system Message-ID: "j2" is so 2001. Before freezing the shiny new build system, consider taking the opportunity to rename "j2sdk" => "jdk" "j2re" => "jre" globally in the new Makefiles. From tim.bell at oracle.com Sat Feb 23 02:31:00 2013 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 22 Feb 2013 18:31:00 -0800 Subject: "j2sdk-image" and new build system In-Reply-To: References: Message-ID: <512829E4.5080803@oracle.com> Hi Martin: > "j2" is so 2001. Before freezing the shiny new build system, consider > taking the opportunity to rename > "j2sdk" => "jdk" > "j2re" => "jre" > globally in the new Makefiles. Agreed. I filed 8008771 "anacronism removal: change use of j2* to jdk,jre etc..." This report should be visible within a few working days at: http://bugs.sun.com/view_bug.do?bug_id=8008771 Tim From christian.thalinger at oracle.com Sat Feb 23 03:55:58 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Feb 2013 19:55:58 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> Message-ID: I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: http://cr.openjdk.java.net/~twisti/8006965/ This would be the first of three fixes: Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} -- Chris On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: > > On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: > >> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. > > How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? > > Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. > > -- Chris > >> >> Thanks, >> /Staffan >> >> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/8006965 >>> >>> 8006965: test_gamma should run with import JDK >>> Reviewed-by: >>> >>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>> JDK n is the version we are actually compiling for). This setup is >>> unsupported and thus should not be done during HotSpot builds. >>> >>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>> running test_gamma. >>> >>> make/bsd/makefiles/buildtree.make >>> make/defs.make >>> make/linux/makefiles/buildtree.make >>> make/solaris/makefiles/buildtree.make >>> >> > From peter.brunet at oracle.com Sat Feb 23 05:16:12 2013 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 22 Feb 2013 23:16:12 -0600 Subject: jfx ant build strangeness Message-ID: <5128509C.3030607@oracle.com> What is causing this? I am in .../controls/jfx but the build is running from .../controls-old3. $ pwd /Users/petebrunet/JavaFX/controls/jfx $ ant -Dhudson.jfx.job.name=8.0-controls-scrum sdk-no-docs Buildfile: /Users/petebrunet/JavaFX/controls-old3/jfx/build.xml ... From peter.brunet at oracle.com Sat Feb 23 05:20:41 2013 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 22 Feb 2013 23:20:41 -0600 Subject: jfx ant build strangeness In-Reply-To: <5128509C.3030607@oracle.com> References: <5128509C.3030607@oracle.com> Message-ID: <512851A9.6080408@oracle.com> Restarting the console solved it. On 2/22/13 11:16 PM, Pete Brunet wrote: > What is causing this? I am in .../controls/jfx but the build is running > from .../controls-old3. > > $ pwd > /Users/petebrunet/JavaFX/controls/jfx > > $ ant -Dhudson.jfx.job.name=8.0-controls-scrum sdk-no-docs > Buildfile: /Users/petebrunet/JavaFX/controls-old3/jfx/build.xml > ... From david.holmes at oracle.com Sat Feb 23 10:29:03 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 23 Feb 2013 20:29:03 +1000 Subject: "j2sdk-image" and new build system In-Reply-To: <512829E4.5080803@oracle.com> References: <512829E4.5080803@oracle.com> Message-ID: <512899EF.7060904@oracle.com> On 23/02/2013 12:31 PM, Tim Bell wrote: > Hi Martin: > >> "j2" is so 2001. Before freezing the shiny new build system, consider >> taking the opportunity to rename >> "j2sdk" => "jdk" >> "j2re" => "jre" >> globally in the new Makefiles. > > Agreed. I filed 8008771 "anacronism removal: change use of j2* to > jdk,jre etc..." > > This report should be visible within a few working days at: > > http://bugs.sun.com/view_bug.do?bug_id=8008771 Just be aware there's a lot more involved in doing this than just changing one a name in a makefile. David > Tim > From david.holmes at oracle.com Sat Feb 23 10:33:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 23 Feb 2013 20:33:42 +1000 Subject: Customizing CFLAGS_JDKLIB etc? Message-ID: <51289B06.2080900@oracle.com> What's the right way to customize these flags? Thanks, David From Alan.Bateman at oracle.com Sat Feb 23 10:45:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Feb 2013 10:45:26 +0000 Subject: "j2sdk-image" and new build system In-Reply-To: <512899EF.7060904@oracle.com> References: <512829E4.5080803@oracle.com> <512899EF.7060904@oracle.com> Message-ID: <51289DC6.6070803@oracle.com> On 23/02/2013 10:29, David Holmes wrote: > > Just be aware there's a lot more involved in doing this than just > changing one a name in a makefile. > You beat to me too! Yes, there are likely a lot of scripts and paths that assume the image name is j2sdk-image or j2re-image so renaming will be a bit disruptive. Also I think the initial goal of the new build system was to get it to the point where it generated the "same bits" as the old build. I assume this is why the new build went for the same directory names as the old build (and probably because of scripts depending on the name too). -Alan From Alan.Bateman at oracle.com Sat Feb 23 11:51:31 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Feb 2013 11:51:31 +0000 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: Message-ID: <5128AD43.2000809@oracle.com> On 22/02/2013 22:03, Martin Buchholz wrote: > Hi Alan, Xueming, build-ers, > > I'd like you to do a code review. > > I've finally figured out why fastdebug jdk occasionally gives > InternalError in the zip code. > > Exception in thread "main" java.lang.InternalError > at java.util.zip.Inflater.init(Native Method) > at java.util.zip.Inflater.(Inflater.java:101) > at java.util.zip.ZipFile.getInflater(ZipFile.java:448) > > It's because: > - jdk changed structure size of z_stream struct > - making jdk zlib incompatible with stock zlib > - as a result of which, it is imperative to keep jdk zlib sequestered > from system zlib > - so need to not export zlib symbols from libzip.so > - so need to tell makefiles to use linker script unconditionally > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ > > I see Sherman has created a bug for this but it turns out that someone else running with fastdebug ran into issues too: 8006319: fastdebug libzip.so is linked with global symbols, allowing symbols to be overridden I see you are proposing to update make/java/zip/Makefile so that is the old build. Looking at makefiles/CompileNativeLibraries.gmk (new build) then it looks to me that it is using the map file. I haven't checking the symbols in a fast debug build to double check so I'm curious if you've seen this with a recent (new) build. -Alan. From martinrb at google.com Sat Feb 23 17:29:33 2013 From: martinrb at google.com (Martin Buchholz) Date: Sat, 23 Feb 2013 09:29:33 -0800 Subject: Suggestion: "make help" should print list of configurations Message-ID: I'm having fun with the shiny new build system. It took me a while to discover that "make help" was exceptionally helpful. However, I was interested in passing a configuration to CONF= and was annoyed there was no clue what to provide. (I wasn't even sure exactly what a "configuration" was) After some trial and error, I discovered that make CONF=bogus would actually give me that precious list of supported configurations. It would be nice if "make help" always printed that list, even though by default it contains only one entry. From martinrb at google.com Sat Feb 23 18:06:35 2013 From: martinrb at google.com (Martin Buchholz) Date: Sat, 23 Feb 2013 10:06:35 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: <5128AD43.2000809@oracle.com> References: <5128AD43.2000809@oracle.com> Message-ID: I am actually encountering this in openjdk7 with the old build system. I can repro the problem in openjdk8 with the old build system, but not the new one. I don't know if you consider this a bug with the new build system - it's supposed to generate the same bits, after all???!! I'm not sure why - I'd guess something to do with VARIANT or FILES_m It's highly dubious whether we should have this extremely subtle and error-prone distinction between release and fastdebug builds at all. Consider fixing this more fundamentally in Mapfile-vers.gmk, or at least document clearly why mapfiles are only on in OPT, and what the consequences might be. ifeq ($(PLATFORM), linux) ifeq ($(VARIANT), OPT) # OPT build MUST have a mapfile? ifndef FILES_m FILES_m = mapfile-vers endif endif # VARIANT Here's a repro recipe on Ubuntu Linux, running javac on any old source file: env LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libz.so" ~/ws/openjdk8/build/linux-amd64-fastdebug/j2sdk-image/bin/javac Main.java An exception has occurred in the compiler (1.8.0-internal). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.InternalError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.(Inflater.java:103) at java.util.zip.ZipFile.getInflater(ZipFile.java:448) at java.util.zip.ZipFile.getInputStream(ZipFile.java:367) at java.util.jar.JarFile.getBytes(JarFile.java:379) at java.util.jar.JarFile.getManifestFromReference(JarFile.java:178) at java.util.jar.JarFile.getManifest(JarFile.java:165) at com.sun.tools.javac.file.FSInfo.getJarClassPath(FSInfo.java:69) at com.sun.tools.javac.file.CacheFSInfo.getJarClassPath(CacheFSInfo.java:94) at com.sun.tools.javac.file.Locations$Path.addJarClassPath(Locations.java:304) at com.sun.tools.javac.file.Locations$Path.addFile(Locations.java:295) at com.sun.tools.javac.file.Locations$Path.addDirectory(Locations.java:217) at com.sun.tools.javac.file.Locations$Path.addDirectories(Locations.java:192) at com.sun.tools.javac.file.Locations$BootClassPathLocationHandler.computePath(Locations.java:630) at com.sun.tools.javac.file.Locations$BootClassPathLocationHandler.lazy(Locations.java:642) at com.sun.tools.javac.file.Locations$BootClassPathLocationHandler.getLocation(Locations.java:576) at com.sun.tools.javac.file.Locations.getLocation(Locations.java:677) at com.sun.tools.javac.file.JavacFileManager.getLocation(JavacFileManager.java:803) at com.sun.tools.javac.file.JavacFileManager.list(JavacFileManager.java:617) at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2699) at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2395) at com.sun.tools.javac.code.Symbol.complete(Symbol.java:434) at com.sun.tools.javac.comp.Enter.visitTopLevel(Enter.java:302) at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:519) at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:262) at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:276) at com.sun.tools.javac.comp.Enter.complete(Enter.java:488) at com.sun.tools.javac.comp.Enter.main(Enter.java:473) at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:990) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:865) at com.sun.tools.javac.main.Main.compile(Main.java:517) at com.sun.tools.javac.main.Main.compile(Main.java:376) at com.sun.tools.javac.main.Main.compile(Main.java:365) at com.sun.tools.javac.main.Main.compile(Main.java:356) at com.sun.tools.javac.Main.compile(Main.java:76) at com.sun.tools.javac.Main.main(Main.java:61) On Sat, Feb 23, 2013 at 3:51 AM, Alan Bateman wrote: > On 22/02/2013 22:03, Martin Buchholz wrote: > > Hi Alan, Xueming, build-ers, > > I'd like you to do a code review. > > I've finally figured out why fastdebug jdk occasionally gives > InternalError in the zip code. > > Exception in thread "main" java.lang.InternalError > at java.util.zip.Inflater.init(Native Method) > at java.util.zip.Inflater.(Inflater.java:101) > at java.util.zip.ZipFile.getInflater(ZipFile.java:448) > > It's because: > - jdk changed structure size of z_stream struct > - making jdk zlib incompatible with stock zlib > - as a result of which, it is imperative to keep jdk zlib sequestered from > system zlib > - so need to not export zlib symbols from libzip.so > - so need to tell makefiles to use linker script unconditionally > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ > > I see Sherman has created a bug for this but it turns out that someone > else running with fastdebug ran into issues too: > > 8006319: fastdebug libzip.so is linked with global symbols, allowing > symbols to be overridden > > I see you are proposing to update make/java/zip/Makefile so that is the > old build. Looking at makefiles/CompileNativeLibraries.gmk (new build) then > it looks to me that it is using the map file. I haven't checking the > symbols in a fast debug build to double check so I'm curious if you've seen > this with a recent (new) build. > > -Alan. > > From martinrb at google.com Sat Feb 23 18:19:27 2013 From: martinrb at google.com (Martin Buchholz) Date: Sat, 23 Feb 2013 10:19:27 -0800 Subject: "j2sdk-image" and new build system In-Reply-To: <51289DC6.6070803@oracle.com> References: <512829E4.5080803@oracle.com> <512899EF.7060904@oracle.com> <51289DC6.6070803@oracle.com> Message-ID: On Sat, Feb 23, 2013 at 2:45 AM, Alan Bateman wrote: > On 23/02/2013 10:29, David Holmes wrote: > >> >> Just be aware there's a lot more involved in doing this than just >> changing one a name in a makefile. >> >> You beat to me too! Yes, there are likely a lot of scripts and paths > that assume the image name is j2sdk-image or j2re-image so renaming will be > a bit disruptive. > > Sure, but you are *already* making a huge disruptive change to build directory layout. People have to change their scripts from linux-amd64/j2sdk-image to linux-x86_64-normal-server-release/images/j2sdk-image Especially the repetition of "image" seems wrong in the new layout. Why not images/j2sdk-image to images/jdk If you really want to keep "j2sdk-image", move it back into its parent directory. > Also I think the initial goal of the new build system was to get it to the > point where it generated the "same bits" as the old build. I assume this is > why the new build went for the same directory names as the old build (and > probably because of scripts depending on the name too). Hopefully the new build system will lead to an increase, not decrease, in overall sanity. From steven.loomis at oracle.com Sat Feb 23 18:38:38 2013 From: steven.loomis at oracle.com (Steven R. Loomis) Date: Sat, 23 Feb 2013 10:38:38 -0800 Subject: _JAVA_OPTIONS confuses version check In-Reply-To: References: Message-ID: <51290CAE.7090102@oracle.com> For reason or reasons unknown (probably related to the old build system), I had this in my environment: _JAVA_OPTIONS=-Dfile.encoding=ASCII This causes the shiny new build system's "java -version" to read the java version as: "Picked up _JAVA_OPTIONS: -Dfile.encoding=ASCII" and fail version check. configure: Found potential Boot JDK using well-known locations (in /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk) configure: Potential Boot JDK found at /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home is incorrect JDK version (Picked up _JAVA_OPTIONS: -Dfile.encoding=ASCII); ignoring configure: (Your Boot JDK must be version 7 or 8) -s On 2/23/13 9:29 AM, Martin Buchholz wrote: > I'm having fun with the shiny new build system. > It took me a while to discover that "make help" was exceptionally helpful. > > However, I was interested in passing a configuration to CONF= and was > annoyed there was no clue what to provide. (I wasn't even sure exactly > what a "configuration" was) > > After some trial and error, I discovered that > > make CONF=bogus > > would actually give me that precious list of supported configurations. > It would be nice if "make help" always printed that list, even though by > default it contains only one entry. From kelly.ohair at oracle.com Sat Feb 23 18:47:46 2013 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Sat, 23 Feb 2013 18:47:46 +0000 Subject: hg: jdk8/build: 8004712: build-infra: Move user guide from web pages to repository Message-ID: <20130223184747.56EEF47D85@hg.openjdk.java.net> Changeset: d3e3d5b06f45 Author: ohair Date: 2013-02-23 10:47 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/d3e3d5b06f45 8004712: build-infra: Move user guide from web pages to repository Summary: Just the initial work, will need more changes. Reviewed-by: tbell ! README ! README-builds.html From martinrb at google.com Sat Feb 23 20:05:52 2013 From: martinrb at google.com (Martin Buchholz) Date: Sat, 23 Feb 2013 12:05:52 -0800 Subject: New build system problems In-Reply-To: References: Message-ID: Hi Erik, Tim, Kelly Here's a proposed fix for you to review: http://cr.openjdk.java.net/~martin/webrevs/openjdk8/COMPILER_CHECK_LIST/ Martin On Fri, Jan 25, 2013 at 3:51 PM, Martin Buchholz wrote: > I was trying out the shiny new build system. > > Problem: configure is not executable - must run bash ./configure > It's traditional for configure scripts to be executable. > > Problem: Your life is hell if you have a non-compiler "cl" command on your > PATH, even on Linux. > > checking for cl... /usr/bin/cl > configure: Resolving CC (as /usr/bin/cl) failed, using /usr/bin/cl > directly. > > with subsequent failure to compile. > > Even if you specify the compiler explicitly, it doesn't help: > > CC=/usr/bin/gcc CXX=/usr/bin/g++ bash ./configure > > Of course, one can work around this by creating a "tools dir", but > excising the unloved cl from the configure script is tempting and effective. > From Alan.Bateman at oracle.com Sat Feb 23 20:12:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Feb 2013 20:12:05 +0000 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: <5128AD43.2000809@oracle.com> Message-ID: <51292295.4040802@oracle.com> On 23/02/2013 18:06, Martin Buchholz wrote: > I am actually encountering this in openjdk7 with the old build system. > I can repro the problem in openjdk8 with the old build system, but not > the new one. > > I don't know if you consider this a bug with the new build system - > it's supposed to generate the same bits, after all???!! > I'm not sure why - I'd guess something to do with VARIANT or FILES_m > > It's highly dubious whether we should have this extremely subtle and > error-prone distinction between release and fastdebug builds at all. Thanks for confirming it's old build only, that was my reading too but without checking. Anyway, I do consider it a bug (in the old build), and really hard to track down too until you see both libz and the JDK's libzip loaded. Kelly might have some insight the product vs. fastdebug difference. -Alan From david.holmes at oracle.com Sat Feb 23 23:09:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Sun, 24 Feb 2013 09:09:32 +1000 Subject: "j2sdk-image" and new build system In-Reply-To: References: <512829E4.5080803@oracle.com> <512899EF.7060904@oracle.com> <51289DC6.6070803@oracle.com> Message-ID: <51294C2C.4040207@oracle.com> On 24/02/2013 4:19 AM, Martin Buchholz wrote: > On Sat, Feb 23, 2013 at 2:45 AM, Alan Bateman > wrote: > > On 23/02/2013 10:29, David Holmes wrote: > > > Just be aware there's a lot more involved in doing this than > just changing one a name in a makefile. > > You beat to me too! Yes, there are likely a lot of scripts and paths > that assume the image name is j2sdk-image or j2re-image so renaming > will be a bit disruptive. > > > Sure, but you are *already* making a huge disruptive change to build > directory layout. People have to change their scripts from > linux-amd64/j2sdk-image > to > linux-x86_64-normal-server-release/images/j2sdk-image Not quite. You can still have full control of the first directory component [1] so for most builds there is no change there at all and no disruption. The additional images directory is also easily accommodated. Scripts/processes that copy the images from path-A to path-B just need to tweak path-A. But if you rename the actual j2sdk-image etc you have to update everything that uses path-B. > Especially the repetition of "image" seems wrong in the new layout. The new build tries to have a top-level directory for each major build component. Hence images has its own directory. David ----- [1] Simplest way is: > mkdir mydir > cd mydir > /configure > Why not > images/j2sdk-image > to > images/jdk > > If you really want to keep "j2sdk-image", move it back into its parent > directory. > > Also I think the initial goal of the new build system was to get it > to the point where it generated the "same bits" as the old build. I > assume this is why the new build went for the same directory names > as the old build (and probably because of scripts depending on the > name too). > > > Hopefully the new build system will lead to an increase, not decrease, > in overall sanity. From dmitry.samersoff at oracle.com Sun Feb 24 07:32:14 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 24 Feb 2013 11:32:14 +0400 Subject: "j2sdk-image" and new build system In-Reply-To: <51294C2C.4040207@oracle.com> References: <512829E4.5080803@oracle.com> <512899EF.7060904@oracle.com> <51289DC6.6070803@oracle.com> <51294C2C.4040207@oracle.com> Message-ID: <5129C1FE.9010805@oracle.com> David, May be we can cleanup names in makefiles, but add something like restore_old_names() doing couple of mv calls to the end of build process. -Dmitry On 2013-02-24 03:09, David Holmes wrote: > On 24/02/2013 4:19 AM, Martin Buchholz wrote: >> On Sat, Feb 23, 2013 at 2:45 AM, Alan Bateman > > wrote: >> >> On 23/02/2013 10:29, David Holmes wrote: >> >> >> Just be aware there's a lot more involved in doing this than >> just changing one a name in a makefile. >> >> You beat to me too! Yes, there are likely a lot of scripts and paths >> that assume the image name is j2sdk-image or j2re-image so renaming >> will be a bit disruptive. >> >> >> Sure, but you are *already* making a huge disruptive change to build >> directory layout. People have to change their scripts from >> linux-amd64/j2sdk-image >> to >> linux-x86_64-normal-server-release/images/j2sdk-image > > Not quite. You can still have full control of the first directory > component [1] so for most builds there is no change there at all and no > disruption. > > The additional images directory is also easily accommodated. > Scripts/processes that copy the images from path-A to path-B just need > to tweak path-A. But if you rename the actual j2sdk-image etc you have > to update everything that uses path-B. > >> Especially the repetition of "image" seems wrong in the new layout. > > The new build tries to have a top-level directory for each major build > component. Hence images has its own directory. > > David > ----- > > [1] Simplest way is: >> mkdir mydir >> cd mydir >> /configure > > > >> Why not >> images/j2sdk-image >> to >> images/jdk >> >> If you really want to keep "j2sdk-image", move it back into its parent >> directory. >> >> Also I think the initial goal of the new build system was to get it >> to the point where it generated the "same bits" as the old build. I >> assume this is why the new build went for the same directory names >> as the old build (and probably because of scripts depending on the >> name too). >> >> >> Hopefully the new build system will lead to an increase, not decrease, >> in overall sanity. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From dmitry.samersoff at oracle.com Sun Feb 24 08:19:49 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 24 Feb 2013 12:19:49 +0400 Subject: New build system problems In-Reply-To: References: Message-ID: <5129CD25.2000003@oracle.com> Martin, 257 if test "x$OPENJDK_TARGET_OS" != xmacosx; then 258 # Do not probe for cc on MacOSX. 259 COMPILER_CHECK_LIST="cc $COMPILER_CHECK_LIST" 260 fi 261 if test "x$OPENJDK_TARGET_OS" == xwindows; then 262 COMPILER_CHECK_LIST="cl $COMPILER_CHECK_LIST" 263 fi 1. for windows compiler checklist become: cl cc gcc I'm not sure we need to check for cc on windows, also gcc build on windows is not supported. So It might be better to be more explicit: 256 COMPILER_CHECK_LIST="cc gcc" # Overriding COMPILER_CHECK_LIST to set OS specific preferences 257 if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then 258 # Do not probe for cc on MacOSX. 259 COMPILER_CHECK_LIST="gcc" 260 fi 261 if test "x$OPENJDK_TARGET_OS" = "xwindows"; then 262 COMPILER_CHECK_LIST="cl" 263 fi 2. Not all versions of test support == as equation. It's better to use single one. and I would prefer to have quotes around xmacosx and xwindows just for consistency. i.e. if test "x$OPENJDK_TARGET_OS" = "xwindows"; -Dmitry On 2013-02-24 00:05, Martin Buchholz wrote: > Hi Erik, Tim, Kelly > > Here's a proposed fix for you to review: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/COMPILER_CHECK_LIST/ > > Martin > > On Fri, Jan 25, 2013 at 3:51 PM, Martin Buchholz wrote: > >> I was trying out the shiny new build system. >> >> Problem: configure is not executable - must run bash ./configure >> It's traditional for configure scripts to be executable. >> >> Problem: Your life is hell if you have a non-compiler "cl" command on your >> PATH, even on Linux. >> >> checking for cl... /usr/bin/cl >> configure: Resolving CC (as /usr/bin/cl) failed, using /usr/bin/cl >> directly. >> >> with subsequent failure to compile. >> >> Even if you specify the compiler explicitly, it doesn't help: >> >> CC=/usr/bin/gcc CXX=/usr/bin/g++ bash ./configure >> >> Of course, one can work around this by creating a "tools dir", but >> excising the unloved cl from the configure script is tempting and effective. >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From david.holmes at oracle.com Sun Feb 24 11:59:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Sun, 24 Feb 2013 21:59:13 +1000 Subject: "j2sdk-image" and new build system In-Reply-To: <5129C1FE.9010805@oracle.com> References: <512829E4.5080803@oracle.com> <512899EF.7060904@oracle.com> <51289DC6.6070803@oracle.com> <51294C2C.4040207@oracle.com> <5129C1FE.9010805@oracle.com> Message-ID: <512A0091.7040709@oracle.com> On 24/02/2013 5:32 PM, Dmitry Samersoff wrote: > David, > > May be we can cleanup names in makefiles, but add something > like > > restore_old_names() > > doing couple of mv calls to the end of build process. The actual makefile changes are very small. The names are defined in spec.gmk.in. The only other references are in comments, the JPRT makefile and in creating the image name for profile JREs. The problem is the outside systems that "know" what the build produces. David > -Dmitry > > > On 2013-02-24 03:09, David Holmes wrote: >> On 24/02/2013 4:19 AM, Martin Buchholz wrote: >>> On Sat, Feb 23, 2013 at 2:45 AM, Alan Bateman >> > wrote: >>> >>> On 23/02/2013 10:29, David Holmes wrote: >>> >>> >>> Just be aware there's a lot more involved in doing this than >>> just changing one a name in a makefile. >>> >>> You beat to me too! Yes, there are likely a lot of scripts and paths >>> that assume the image name is j2sdk-image or j2re-image so renaming >>> will be a bit disruptive. >>> >>> >>> Sure, but you are *already* making a huge disruptive change to build >>> directory layout. People have to change their scripts from >>> linux-amd64/j2sdk-image >>> to >>> linux-x86_64-normal-server-release/images/j2sdk-image >> >> Not quite. You can still have full control of the first directory >> component [1] so for most builds there is no change there at all and no >> disruption. >> >> The additional images directory is also easily accommodated. >> Scripts/processes that copy the images from path-A to path-B just need >> to tweak path-A. But if you rename the actual j2sdk-image etc you have >> to update everything that uses path-B. >> >>> Especially the repetition of "image" seems wrong in the new layout. >> >> The new build tries to have a top-level directory for each major build >> component. Hence images has its own directory. >> >> David >> ----- >> >> [1] Simplest way is: >>> mkdir mydir >>> cd mydir >>> /configure >> >> >> >>> Why not >>> images/j2sdk-image >>> to >>> images/jdk >>> >>> If you really want to keep "j2sdk-image", move it back into its parent >>> directory. >>> >>> Also I think the initial goal of the new build system was to get it >>> to the point where it generated the "same bits" as the old build. I >>> assume this is why the new build went for the same directory names >>> as the old build (and probably because of scripts depending on the >>> name too). >>> >>> >>> Hopefully the new build system will lead to an increase, not decrease, >>> in overall sanity. > > From mike.duigou at oracle.com Sun Feb 24 15:08:43 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 24 Feb 2013 07:08:43 -0800 Subject: Suggestion: "make help" should print list of configurations In-Reply-To: References: Message-ID: <54B7901A-A75F-45E9-BA5C-B2E9FAC9C68E@oracle.com> Perfect timing on asking this question Martin. I have been wondering about exactly the same question myself for IDE and external tooling support. To make parsing easier I would prefer if the target which displayed information about the configurations was relatively unadorned. Mike On Feb 23 2013, at 09:29 , Martin Buchholz wrote: > I'm having fun with the shiny new build system. > It took me a while to discover that "make help" was exceptionally helpful. > > However, I was interested in passing a configuration to CONF= and was > annoyed there was no clue what to provide. (I wasn't even sure exactly > what a "configuration" was) > > After some trial and error, I discovered that > > make CONF=bogus > > would actually give me that precious list of supported configurations. > It would be nice if "make help" always printed that list, even though by > default it contains only one entry. From david.holmes at oracle.com Sun Feb 24 22:54:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 08:54:55 +1000 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> Message-ID: <512A9A3F.4070402@oracle.com> On 23/02/2013 1:55 PM, Christian Thalinger wrote: > I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: > > http://cr.openjdk.java.net/~twisti/8006965/ > > This would be the first of three fixes: > > Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets This logic is not suitable: 541 # Testing the built JVM 542 ifeq ($(JAVA_HOME),) 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma 544 else 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma 546 endif I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. And this addition still makes no sense to me: MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) Why do you need to add BOOTDIR to the MAKE_ARGS? David > Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 > > Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} > > -- Chris > > On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: > >> >> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >> >>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >> >> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >> >> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >> >> -- Chris >> >>> >>> Thanks, >>> /Staffan >>> >>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/8006965 >>>> >>>> 8006965: test_gamma should run with import JDK >>>> Reviewed-by: >>>> >>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>> JDK n is the version we are actually compiling for). This setup is >>>> unsupported and thus should not be done during HotSpot builds. >>>> >>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>> running test_gamma. >>>> >>>> make/bsd/makefiles/buildtree.make >>>> make/defs.make >>>> make/linux/makefiles/buildtree.make >>>> make/solaris/makefiles/buildtree.make >>>> >>> >> > From david.holmes at oracle.com Sun Feb 24 23:27:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 09:27:01 +1000 Subject: Customizing CFLAGS_JDKLIB etc? In-Reply-To: <51289B06.2080900@oracle.com> References: <51289B06.2080900@oracle.com> Message-ID: <512AA1C5.5090701@oracle.com> On 23/02/2013 8:33 PM, David Holmes wrote: > What's the right way to customize these flags? --with-extra-cflags For some reason I thought the above was only for legacy hotspot stuff. David > Thanks, > David From david.holmes at oracle.com Sun Feb 24 23:34:31 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 09:34:31 +1000 Subject: RFR: 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries In-Reply-To: <5D7CCEEA-EA5A-4D7C-833A-EB045ACF1AA9@oracle.com> References: <899E92AE-F8A0-4873-B8DC-EE642B615840@oracle.com> <51274F10.6020208@oracle.com> <5D7CCEEA-EA5A-4D7C-833A-EB045ACF1AA9@oracle.com> Message-ID: <512AA387.5020401@oracle.com> Adding back build-dev On 23/02/2013 7:33 AM, Vladimir Danushevsky wrote: > Thanks, webrev updated > http://cr.openjdk.java.net/~vladidan/8005545/webrev.01/ > What is missing from this is documentation on how this new variable should be set in a build. The proposed changes rely on two things happening: a) JDK_ARCH_ABI_PROP_NAME=foo is either passed as a make variable, or set in the environment; and b) --with-extra-cflags is used to pass -DJDK_ARCH_ABI_PROP_NAME=foo This would go into the top-level README-builds.html, if people think it needs to be documented. David > On Feb 22, 2013, at 5:57 AM, Alan Bateman wrote: > >> On 21/02/2013 22:02, Vladimir Danushevsky wrote: >>> : >>> >>> Webrev: >>> http://cr.openjdk.java.net/~vladidan/8005545/webrev.00/ >>> >>> >>> Separate change to the build script (e.g. in ARM Hard-Float ABI case): >>> setenv ARCHABIPROPNAME gnueabihf >>> -DARCHABIPROPNAME="\"$(ARCHABIPROPNAME)\"" is passed to the CFLAGS >>> >> I agree with Bob on the naming, otherwise it looks okay to me. >> >> On the release file and Images.gmk then jdk/tl was sync'ed up >> yesterday so you will probably need to re-base the patch. >> >> -Alan > From david.holmes at oracle.com Mon Feb 25 00:05:27 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 10:05:27 +1000 Subject: _JAVA_OPTIONS confuses version check In-Reply-To: <51290CAE.7090102@oracle.com> References: <51290CAE.7090102@oracle.com> Message-ID: <512AAAC7.5090109@oracle.com> On 24/02/2013 4:38 AM, Steven R. Loomis wrote: > For reason or reasons unknown (probably related to the old build > system), I had this in my environment: > _JAVA_OPTIONS=-Dfile.encoding=ASCII > This causes the shiny new build system's "java -version" to read the > java version as: > "Picked up _JAVA_OPTIONS: -Dfile.encoding=ASCII" > and fail version check. I would consider this a "user error" not a bug in configure. At least it is clear what caused the problem. There are other environment variables (eg _JAVA_LAUNCHER_DEBUG) and files that can impact the way java behaves and we should not expect configure to be aware of all these and try to compensate. David ----- > configure: Found potential Boot JDK using well-known locations (in > /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk) > configure: Potential Boot JDK found at > /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home is > incorrect JDK version (Picked up _JAVA_OPTIONS: -Dfile.encoding=ASCII); > ignoring > configure: (Your Boot JDK must be version 7 or 8) > > -s > > On 2/23/13 9:29 AM, Martin Buchholz wrote: >> I'm having fun with the shiny new build system. >> It took me a while to discover that "make help" was exceptionally >> helpful. >> >> However, I was interested in passing a configuration to CONF= and was >> annoyed there was no clue what to provide. (I wasn't even sure exactly >> what a "configuration" was) >> >> After some trial and error, I discovered that >> >> make CONF=bogus >> >> would actually give me that precious list of supported configurations. >> It would be nice if "make help" always printed that list, even though by >> default it contains only one entry. > From david.holmes at oracle.com Mon Feb 25 00:14:45 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 10:14:45 +1000 Subject: New build system problems In-Reply-To: References: Message-ID: <512AACF5.2090705@oracle.com> Hi Martin, 257 if test "x$OPENJDK_TARGET_OS" != xmacosx; then 258 # Do not probe for cc on MacOSX. 259 COMPILER_CHECK_LIST="cc $COMPILER_CHECK_LIST" 260 fi This is either testing the wrong os - should be Solaris - or using the wrong compiler cc->cl The configure way of doing things was intended to be "here's a list of potential compilers try and find one". But the reality is that each platform really only wants to use one specific compiler: - linux -> gcc - solaris -> cc - windows -> cl Seems to me we should stop pretending there is some generality here and just hardwire these selections, allowing $CC/$CXX to override PS. No executable files in the repositories hence non-executable configure script. David ----- On 24/02/2013 6:05 AM, Martin Buchholz wrote: > Hi Erik, Tim, Kelly > > Here's a proposed fix for you to review: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/COMPILER_CHECK_LIST/ > > Martin > > On Fri, Jan 25, 2013 at 3:51 PM, Martin Buchholz wrote: > >> I was trying out the shiny new build system. >> >> Problem: configure is not executable - must run bash ./configure >> It's traditional for configure scripts to be executable. >> >> Problem: Your life is hell if you have a non-compiler "cl" command on your >> PATH, even on Linux. >> >> checking for cl... /usr/bin/cl >> configure: Resolving CC (as /usr/bin/cl) failed, using /usr/bin/cl >> directly. >> >> with subsequent failure to compile. >> >> Even if you specify the compiler explicitly, it doesn't help: >> >> CC=/usr/bin/gcc CXX=/usr/bin/g++ bash ./configure >> >> Of course, one can work around this by creating a "tools dir", but >> excising the unloved cl from the configure script is tempting and effective. >> From david.holmes at oracle.com Mon Feb 25 00:18:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 10:18:09 +1000 Subject: New build system problems In-Reply-To: <512AACF5.2090705@oracle.com> References: <512AACF5.2090705@oracle.com> Message-ID: <512AADC1.7030400@oracle.com> On 25/02/2013 10:14 AM, David Holmes wrote: > Hi Martin, > > 257 if test "x$OPENJDK_TARGET_OS" != xmacosx; then > 258 # Do not probe for cc on MacOSX. > 259 COMPILER_CHECK_LIST="cc $COMPILER_CHECK_LIST" > 260 fi > > This is either testing the wrong os - should be Solaris - or using the > wrong compiler cc->cl Oops - sorry - misread the != > The configure way of doing things was intended to be "here's a list of > potential compilers try and find one". But the reality is that each > platform really only wants to use one specific compiler: > - linux -> gcc > - solaris -> cc > - windows -> cl - macosx -> gcc David ----- > > Seems to me we should stop pretending there is some generality here and > just hardwire these selections, allowing $CC/$CXX to override > > PS. No executable files in the repositories hence non-executable > configure script. > > David > ----- > > On 24/02/2013 6:05 AM, Martin Buchholz wrote: >> Hi Erik, Tim, Kelly >> >> Here's a proposed fix for you to review: >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/COMPILER_CHECK_LIST/ >> >> Martin >> >> On Fri, Jan 25, 2013 at 3:51 PM, Martin Buchholz >> wrote: >> >>> I was trying out the shiny new build system. >>> >>> Problem: configure is not executable - must run bash ./configure >>> It's traditional for configure scripts to be executable. >>> >>> Problem: Your life is hell if you have a non-compiler "cl" command on >>> your >>> PATH, even on Linux. >>> >>> checking for cl... /usr/bin/cl >>> configure: Resolving CC (as /usr/bin/cl) failed, using /usr/bin/cl >>> directly. >>> >>> with subsequent failure to compile. >>> >>> Even if you specify the compiler explicitly, it doesn't help: >>> >>> CC=/usr/bin/gcc CXX=/usr/bin/g++ bash ./configure >>> >>> Of course, one can work around this by creating a "tools dir", but >>> excising the unloved cl from the configure script is tempting and >>> effective. >>> From Alan.Bateman at oracle.com Mon Feb 25 14:54:52 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Feb 2013 14:54:52 +0000 Subject: 8008808: Allowed dependencies added by JDK-8008481 no longer required Message-ID: <512B7B3C.2060301@oracle.com> Last week, David Holmes had to do a temporary addition to refs.allowed (used by the dependency analyzer in the profiles build) in order to get profiles over the line (a last minute glitch caused by closed code). The temporary addition can now be removed so I'd like to get that done before it is forgotten. The diffs attached is the proposed change. Thanks, -Alan. diff --git a/make/tools/src/build/tools/deps/refs.allowed b/make/tools/src/build/tools/deps/refs.allowed --- a/make/tools/src/build/tools/deps/refs.allowed +++ b/make/tools/src/build/tools/deps/refs.allowed @@ -33,8 +33,3 @@ # java.beans.PropertyChangeListener=java.util.logging.LogManager,sun.org.mozilla.javascript.internal.Context,compact1,compact2,compact3 java.beans.PropertyChangeEvent=sun.org.mozilla.javascript.internal.Context,compact3 - -# JFR traces even in builds with JFR disabled -com.oracle.jrockit.jfr.FlightRecorder: com.sun.management.MissionControl, compact3 -com.oracle.jrockit.jfr.management.FlightRecorderMBean: com.sun.management.MissionControl, compact3 - From tim.bell at oracle.com Mon Feb 25 15:48:19 2013 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 25 Feb 2013 07:48:19 -0800 Subject: 8008808: Allowed dependencies added by JDK-8008481 no longer required In-Reply-To: <512B7B3C.2060301@oracle.com> References: <512B7B3C.2060301@oracle.com> Message-ID: <512B87C3.9050705@oracle.com> Alan: > Last week, David Holmes had to do a temporary addition to refs.allowed > (used by the dependency analyzer in the profiles build) in order to > get profiles over the line (a last minute glitch caused by closed > code). The temporary addition can now be removed so I'd like to get > that done before it is forgotten. The diffs attached is the proposed > change. > > Thanks, > > -Alan. > > > diff --git a/make/tools/src/build/tools/deps/refs.allowed > b/make/tools/src/build/tools/deps/refs.allowed > --- a/make/tools/src/build/tools/deps/refs.allowed > +++ b/make/tools/src/build/tools/deps/refs.allowed > @@ -33,8 +33,3 @@ > # > java.beans.PropertyChangeListener=java.util.logging.LogManager,sun.org.mozilla.javascript.internal.Context,compact1,compact2,compact3 > > java.beans.PropertyChangeEvent=sun.org.mozilla.javascript.internal.Context,compact3 > > - > -# JFR traces even in builds with JFR disabled > -com.oracle.jrockit.jfr.FlightRecorder: > com.sun.management.MissionControl, compact3 > -com.oracle.jrockit.jfr.management.FlightRecorderMBean: > com.sun.management.MissionControl, compact3 > - Looks good to me. Tim From chris.hegarty at oracle.com Mon Feb 25 16:14:45 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 25 Feb 2013 16:14:45 +0000 Subject: 8008808: Allowed dependencies added by JDK-8008481 no longer required In-Reply-To: <512B7B3C.2060301@oracle.com> References: <512B7B3C.2060301@oracle.com> Message-ID: <512B8DF5.9000704@oracle.com> Looks fine to me. -Chris. On 25/02/2013 14:54, Alan Bateman wrote: > > Last week, David Holmes had to do a temporary addition to refs.allowed > (used by the dependency analyzer in the profiles build) in order to get > profiles over the line (a last minute glitch caused by closed code). The > temporary addition can now be removed so I'd like to get that done > before it is forgotten. The diffs attached is the proposed change. > > Thanks, > > -Alan. > > > diff --git a/make/tools/src/build/tools/deps/refs.allowed > b/make/tools/src/build/tools/deps/refs.allowed > --- a/make/tools/src/build/tools/deps/refs.allowed > +++ b/make/tools/src/build/tools/deps/refs.allowed > @@ -33,8 +33,3 @@ > # > java.beans.PropertyChangeListener=java.util.logging.LogManager,sun.org.mozilla.javascript.internal.Context,compact1,compact2,compact3 > > java.beans.PropertyChangeEvent=sun.org.mozilla.javascript.internal.Context,compact3 > > - > -# JFR traces even in builds with JFR disabled > -com.oracle.jrockit.jfr.FlightRecorder: > com.sun.management.MissionControl, compact3 > -com.oracle.jrockit.jfr.management.FlightRecorderMBean: > com.sun.management.MissionControl, compact3 > - From peter.brunet at oracle.com Mon Feb 25 17:01:51 2013 From: peter.brunet at oracle.com (Pete Brunet) Date: Mon, 25 Feb 2013 11:01:51 -0600 Subject: current clone of jfx is crashing Message-ID: <512B98FF.4080206@oracle.com> The current clone of jfx is crashing when running the HelloButton demo. Upgrading from 7u9 to 7u15 didn't help. Using the jfxrt.jar from 7u15 works OK, but not the one built from the cloned repo. -Pete # EXCEPTION_ACCESS_VIOLATION (0xc0000005) # Problematic frame: # V [jvm.dll+0xfb0a1] j com.sun.glass.ui.win.WinApplication._runLoop(Ljava/lang/Runnable;)V+0 j com.sun.glass.ui.win.WinApplication.access$300(Lcom/sun/glass/ui/win/WinApplication;Ljava/lang/Runnable;)V+2 j com.sun.glass.ui.win.WinApplication$3$1.run()V+25 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub Java Threads: ( => current thread ) =>0x000000000ca2e800 JavaThread "WindowsNativeRunloopThread" [_thread_in_vm, id=6392, stack(0x000000000df40000,0x000000000e040000)] 0x000000000b1b8800 JavaThread "Thread-2" daemon [_thread_blocked, id=3584, stack(0x000000000dd70000,0x000000000de70000)] 0x000000000b249800 JavaThread "QuantumRenderer-0" daemon [_thread_blocked, id=4624, stack(0x000000000cfb0000,0x000000000d0b0000)] 0x000000000b1b4800 JavaThread "JavaFX-Launcher" [_thread_blocked, id=3228, stack(0x000000000cdd0000,0x000000000ced0000)] 0x000000000b19a800 JavaThread "Service Thread" daemon [_thread_blocked, id=3868, stack(0x000000000c6a0000,0x000000000c7a0000)] 0x000000000b197800 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=7164, stack(0x000000000c430000,0x000000000c530000)] 0x000000000b189800 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=6356, stack(0x000000000c1e0000,0x000000000c2e0000)] 0x000000000b187000 JavaThread "Attach Listener" daemon [_thread_blocked, id=7100, stack(0x000000000c0e0000,0x000000000c1e0000)] 0x000000000b185800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=4864, stack(0x000000000bc40000,0x000000000bd40000)] 0x000000000b0ff000 JavaThread "Finalizer" daemon [_thread_blocked, id=4360, stack(0x000000000bfb0000,0x000000000c0b0000)] 0x000000000b0f5000 JavaThread "Reference Handler" daemon [_thread_blocked, id=6668, stack(0x000000000beb0000,0x000000000bfb0000)] 0x0000000001dad000 JavaThread "main" [_thread_blocked, id=3972, stack(0x0000000002420000,0x0000000002520000)] From kelly.ohair at oracle.com Mon Feb 25 17:18:45 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 25 Feb 2013 09:18:45 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: <51292295.4040802@oracle.com> References: <5128AD43.2000809@oracle.com> <51292295.4040802@oracle.com> Message-ID: On Feb 23, 2013, at 12:12 PM, Alan Bateman wrote: > On 23/02/2013 18:06, Martin Buchholz wrote: >> I am actually encountering this in openjdk7 with the old build system. >> I can repro the problem in openjdk8 with the old build system, but not the new one. >> >> I don't know if you consider this a bug with the new build system - it's supposed to generate the same bits, after all???!! >> I'm not sure why - I'd guess something to do with VARIANT or FILES_m >> >> It's highly dubious whether we should have this extremely subtle and error-prone distinction between release and fastdebug builds at all. > Thanks for confirming it's old build only, that was my reading too but without checking. > > Anyway, I do consider it a bug (in the old build), and really hard to track down too until you see both libz and the JDK's libzip loaded. Kelly might have some insight the product vs. fastdebug difference. I have filed many issues over the years asking that mapfiles (or version scripts) be used to limit the visibility of extern symbols in Solaris and Linux. Most developers fail to understand the importance of this. I have also always wanted the fastdebug libraries and even debug build libraries to be 'plug&play' so that they exported the exact same externs and same prototypes, and could be plopped into a product build to isolate problems in just one single library. Unfortunately, some teams have added additional externs to the debug versions and that would imply the need for a different mapfile, so I suspect the easy path was to just not use a mapfile with the debug builds. It is rare that this is an issue, but obviously this is a case where it was. The policy should be that ALL shared libraries be scoped and only expose the extern symbols needed. However, with the old builds being this way all along, I see no need to go into the old builds to fix this. We have so much work to do as it is. -kto > > -Alan From peter.brunet at oracle.com Mon Feb 25 17:26:40 2013 From: peter.brunet at oracle.com (Pete Brunet) Date: Mon, 25 Feb 2013 11:26:40 -0600 Subject: current clone of jfx is crashing In-Reply-To: <512B98FF.4080206@oracle.com> References: <512B98FF.4080206@oracle.com> Message-ID: <512B9ED0.7020900@oracle.com> p.s. It fails on Win but not Mac. On 2/25/13 11:01 AM, Pete Brunet wrote: > The current clone of jfx is crashing when running the HelloButton demo. > Upgrading from 7u9 to 7u15 didn't help. Using the jfxrt.jar from 7u15 > works OK, but not the one built from the cloned repo. -Pete > > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) > > # Problematic frame: > # V [jvm.dll+0xfb0a1] > > j com.sun.glass.ui.win.WinApplication._runLoop(Ljava/lang/Runnable;)V+0 > j > com.sun.glass.ui.win.WinApplication.access$300(Lcom/sun/glass/ui/win/WinApplication;Ljava/lang/Runnable;)V+2 > j com.sun.glass.ui.win.WinApplication$3$1.run()V+25 > j java.lang.Thread.run()V+11 > v ~StubRoutines::call_stub > > Java Threads: ( => current thread ) > =>0x000000000ca2e800 JavaThread "WindowsNativeRunloopThread" > [_thread_in_vm, id=6392, stack(0x000000000df40000,0x000000000e040000)] > 0x000000000b1b8800 JavaThread "Thread-2" daemon [_thread_blocked, > id=3584, stack(0x000000000dd70000,0x000000000de70000)] > 0x000000000b249800 JavaThread "QuantumRenderer-0" daemon > [_thread_blocked, id=4624, stack(0x000000000cfb0000,0x000000000d0b0000)] > 0x000000000b1b4800 JavaThread "JavaFX-Launcher" [_thread_blocked, > id=3228, stack(0x000000000cdd0000,0x000000000ced0000)] > 0x000000000b19a800 JavaThread "Service Thread" daemon > [_thread_blocked, id=3868, stack(0x000000000c6a0000,0x000000000c7a0000)] > 0x000000000b197800 JavaThread "C2 CompilerThread1" daemon > [_thread_blocked, id=7164, stack(0x000000000c430000,0x000000000c530000)] > 0x000000000b189800 JavaThread "C2 CompilerThread0" daemon > [_thread_blocked, id=6356, stack(0x000000000c1e0000,0x000000000c2e0000)] > 0x000000000b187000 JavaThread "Attach Listener" daemon > [_thread_blocked, id=7100, stack(0x000000000c0e0000,0x000000000c1e0000)] > 0x000000000b185800 JavaThread "Signal Dispatcher" daemon > [_thread_blocked, id=4864, stack(0x000000000bc40000,0x000000000bd40000)] > 0x000000000b0ff000 JavaThread "Finalizer" daemon [_thread_blocked, > id=4360, stack(0x000000000bfb0000,0x000000000c0b0000)] > 0x000000000b0f5000 JavaThread "Reference Handler" daemon > [_thread_blocked, id=6668, stack(0x000000000beb0000,0x000000000bfb0000)] > 0x0000000001dad000 JavaThread "main" [_thread_blocked, id=3972, > stack(0x0000000002420000,0x0000000002520000)] > > From steven.loomis at oracle.com Mon Feb 25 18:37:13 2013 From: steven.loomis at oracle.com (Steven R. Loomis) Date: Mon, 25 Feb 2013 10:37:13 -0800 Subject: _JAVA_OPTIONS confuses version check In-Reply-To: <512AAAC7.5090109@oracle.com> References: <51290CAE.7090102@oracle.com> <512AAAC7.5090109@oracle.com> Message-ID: <512BAF59.9060106@oracle.com> Fair enough. It was a bump between old and new build systems, just wanted to note it. -s On 2/24/13 4:05 PM, David Holmes wrote: > On 24/02/2013 4:38 AM, Steven R. Loomis wrote: >> For reason or reasons unknown (probably related to the old build >> system), I had this in my environment: >> _JAVA_OPTIONS=-Dfile.encoding=ASCII >> This causes the shiny new build system's "java -version" to read the >> java version as: >> "Picked up _JAVA_OPTIONS: -Dfile.encoding=ASCII" >> and fail version check. > > I would consider this a "user error" not a bug in configure. At least > it is clear what caused the problem. There are other environment > variables (eg _JAVA_LAUNCHER_DEBUG) and files that can impact the way > java behaves and we should not expect configure to be aware of all > these and try to compensate. > > David > ----- > >> configure: Found potential Boot JDK using well-known locations (in >> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk) >> configure: Potential Boot JDK found at >> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home is >> incorrect JDK version (Picked up _JAVA_OPTIONS: -Dfile.encoding=ASCII); >> ignoring >> configure: (Your Boot JDK must be version 7 or 8) >> >> -s >> >> On 2/23/13 9:29 AM, Martin Buchholz wrote: >>> I'm having fun with the shiny new build system. >>> It took me a while to discover that "make help" was exceptionally >>> helpful. >>> >>> However, I was interested in passing a configuration to CONF= and was >>> annoyed there was no clue what to provide. (I wasn't even sure exactly >>> what a "configuration" was) >>> >>> After some trial and error, I discovered that >>> >>> make CONF=bogus >>> >>> would actually give me that precious list of supported configurations. >>> It would be nice if "make help" always printed that list, even >>> though by >>> default it contains only one entry. >> From christian.thalinger at oracle.com Mon Feb 25 18:42:13 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 25 Feb 2013 10:42:13 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <512A9A3F.4070402@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> Message-ID: <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: > On 23/02/2013 1:55 PM, Christian Thalinger wrote: >> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >> >> http://cr.openjdk.java.net/~twisti/8006965/ >> >> This would be the first of three fixes: >> >> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets > > This logic is not suitable: > > 541 # Testing the built JVM > 542 ifeq ($(JAVA_HOME),) > 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma > 544 else > 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma > 546 endif > > I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! That's not entirely correct. test_gamma uses your JAVA_HOME setting: cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma JAVA_HOME must point to a 64-bit OpenJDK. And here comes this little snippet into play: -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. > > I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. > > I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. -- Chris > > And this addition still makes no sense to me: > > MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) > > Why do you need to add BOOTDIR to the MAKE_ARGS? > > David > > >> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >> >> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >> >> -- Chris >> >> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >> >>> >>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>> >>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>> >>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>> >>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>> >>> -- Chris >>> >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>> >>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>> >>>>> 8006965: test_gamma should run with import JDK >>>>> Reviewed-by: >>>>> >>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>> JDK n is the version we are actually compiling for). This setup is >>>>> unsupported and thus should not be done during HotSpot builds. >>>>> >>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>> running test_gamma. >>>>> >>>>> make/bsd/makefiles/buildtree.make >>>>> make/defs.make >>>>> make/linux/makefiles/buildtree.make >>>>> make/solaris/makefiles/buildtree.make >>>>> >>>> >>> >> From peter.brunet at oracle.com Mon Feb 25 21:00:06 2013 From: peter.brunet at oracle.com (Pete Brunet) Date: Mon, 25 Feb 2013 15:00:06 -0600 Subject: current clone of jfx is crashing In-Reply-To: <512B9ED0.7020900@oracle.com> References: <512B98FF.4080206@oracle.com> <512B9ED0.7020900@oracle.com> Message-ID: <512BD0D6.7050308@oracle.com> Another p.s. - the build/repo info... ant -Dhudson.jfx.job.name=8.0-controls-scrum sdk-no-docs On 2/25/13 11:26 AM, Pete Brunet wrote: > p.s. It fails on Win but not Mac. > > On 2/25/13 11:01 AM, Pete Brunet wrote: >> The current clone of jfx is crashing when running the HelloButton demo. >> Upgrading from 7u9 to 7u15 didn't help. Using the jfxrt.jar from 7u15 >> works OK, but not the one built from the cloned repo. -Pete >> >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) >> >> # Problematic frame: >> # V [jvm.dll+0xfb0a1] >> >> j com.sun.glass.ui.win.WinApplication._runLoop(Ljava/lang/Runnable;)V+0 >> j >> com.sun.glass.ui.win.WinApplication.access$300(Lcom/sun/glass/ui/win/WinApplication;Ljava/lang/Runnable;)V+2 >> j com.sun.glass.ui.win.WinApplication$3$1.run()V+25 >> j java.lang.Thread.run()V+11 >> v ~StubRoutines::call_stub >> >> Java Threads: ( => current thread ) >> =>0x000000000ca2e800 JavaThread "WindowsNativeRunloopThread" >> [_thread_in_vm, id=6392, stack(0x000000000df40000,0x000000000e040000)] >> 0x000000000b1b8800 JavaThread "Thread-2" daemon [_thread_blocked, >> id=3584, stack(0x000000000dd70000,0x000000000de70000)] >> 0x000000000b249800 JavaThread "QuantumRenderer-0" daemon >> [_thread_blocked, id=4624, stack(0x000000000cfb0000,0x000000000d0b0000)] >> 0x000000000b1b4800 JavaThread "JavaFX-Launcher" [_thread_blocked, >> id=3228, stack(0x000000000cdd0000,0x000000000ced0000)] >> 0x000000000b19a800 JavaThread "Service Thread" daemon >> [_thread_blocked, id=3868, stack(0x000000000c6a0000,0x000000000c7a0000)] >> 0x000000000b197800 JavaThread "C2 CompilerThread1" daemon >> [_thread_blocked, id=7164, stack(0x000000000c430000,0x000000000c530000)] >> 0x000000000b189800 JavaThread "C2 CompilerThread0" daemon >> [_thread_blocked, id=6356, stack(0x000000000c1e0000,0x000000000c2e0000)] >> 0x000000000b187000 JavaThread "Attach Listener" daemon >> [_thread_blocked, id=7100, stack(0x000000000c0e0000,0x000000000c1e0000)] >> 0x000000000b185800 JavaThread "Signal Dispatcher" daemon >> [_thread_blocked, id=4864, stack(0x000000000bc40000,0x000000000bd40000)] >> 0x000000000b0ff000 JavaThread "Finalizer" daemon [_thread_blocked, >> id=4360, stack(0x000000000bfb0000,0x000000000c0b0000)] >> 0x000000000b0f5000 JavaThread "Reference Handler" daemon >> [_thread_blocked, id=6668, stack(0x000000000beb0000,0x000000000bfb0000)] >> 0x0000000001dad000 JavaThread "main" [_thread_blocked, id=3972, >> stack(0x0000000002420000,0x0000000002520000)] >> >> From tim.bell at oracle.com Mon Feb 25 21:19:18 2013 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 25 Feb 2013 13:19:18 -0800 Subject: current clone of jfx is crashing In-Reply-To: <512B9ED0.7020900@oracle.com> References: <512B98FF.4080206@oracle.com> <512B9ED0.7020900@oracle.com> Message-ID: <512BD556.8030801@oracle.com> Hi Pete: > p.s. It fails on Win but not Mac. I did some searching on https://jbs.oracle.com/bugs/browse/JDK, but did not find an open bug report. Maybe I am looking in the wrong bug tracking system. Do you have any contacts in the JavaFX teams? If so, please reach out to them. I'm not sure how any are on the JDK build list. Tim > On 2/25/13 11:01 AM, Pete Brunet wrote: >> The current clone of jfx is crashing when running the HelloButton demo. >> Upgrading from 7u9 to 7u15 didn't help. Using the jfxrt.jar from 7u15 >> works OK, but not the one built from the cloned repo. -Pete >> >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) >> >> # Problematic frame: >> # V [jvm.dll+0xfb0a1] >> >> j com.sun.glass.ui.win.WinApplication._runLoop(Ljava/lang/Runnable;)V+0 >> j >> com.sun.glass.ui.win.WinApplication.access$300(Lcom/sun/glass/ui/win/WinApplication;Ljava/lang/Runnable;)V+2 >> j com.sun.glass.ui.win.WinApplication$3$1.run()V+25 >> j java.lang.Thread.run()V+11 >> v ~StubRoutines::call_stub >> >> Java Threads: ( => current thread ) >> =>0x000000000ca2e800 JavaThread "WindowsNativeRunloopThread" >> [_thread_in_vm, id=6392, stack(0x000000000df40000,0x000000000e040000)] >> 0x000000000b1b8800 JavaThread "Thread-2" daemon [_thread_blocked, >> id=3584, stack(0x000000000dd70000,0x000000000de70000)] >> 0x000000000b249800 JavaThread "QuantumRenderer-0" daemon >> [_thread_blocked, id=4624, stack(0x000000000cfb0000,0x000000000d0b0000)] >> 0x000000000b1b4800 JavaThread "JavaFX-Launcher" [_thread_blocked, >> id=3228, stack(0x000000000cdd0000,0x000000000ced0000)] >> 0x000000000b19a800 JavaThread "Service Thread" daemon >> [_thread_blocked, id=3868, stack(0x000000000c6a0000,0x000000000c7a0000)] >> 0x000000000b197800 JavaThread "C2 CompilerThread1" daemon >> [_thread_blocked, id=7164, stack(0x000000000c430000,0x000000000c530000)] >> 0x000000000b189800 JavaThread "C2 CompilerThread0" daemon >> [_thread_blocked, id=6356, stack(0x000000000c1e0000,0x000000000c2e0000)] >> 0x000000000b187000 JavaThread "Attach Listener" daemon >> [_thread_blocked, id=7100, stack(0x000000000c0e0000,0x000000000c1e0000)] >> 0x000000000b185800 JavaThread "Signal Dispatcher" daemon >> [_thread_blocked, id=4864, stack(0x000000000bc40000,0x000000000bd40000)] >> 0x000000000b0ff000 JavaThread "Finalizer" daemon [_thread_blocked, >> id=4360, stack(0x000000000bfb0000,0x000000000c0b0000)] >> 0x000000000b0f5000 JavaThread "Reference Handler" daemon >> [_thread_blocked, id=6668, stack(0x000000000beb0000,0x000000000bfb0000)] >> 0x0000000001dad000 JavaThread "main" [_thread_blocked, id=3972, >> stack(0x0000000002420000,0x0000000002520000)] >> >> From martinrb at google.com Mon Feb 25 21:27:30 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 25 Feb 2013 13:27:30 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: <5128AD43.2000809@oracle.com> <51292295.4040802@oracle.com> Message-ID: Kelly, Thanks. I think we agree. I think we have consensus that my change is an improvement and should be committed. Can I haz approval? I'm not brave enough to try to change the default for all mapfiles, although I would support Kelly or anyone else who tries. Martin On Mon, Feb 25, 2013 at 9:18 AM, Kelly O'Hair wrote: > > On Feb 23, 2013, at 12:12 PM, Alan Bateman wrote: > > > On 23/02/2013 18:06, Martin Buchholz wrote: > >> I am actually encountering this in openjdk7 with the old build system. > >> I can repro the problem in openjdk8 with the old build system, but not > the new one. > >> > >> I don't know if you consider this a bug with the new build system - > it's supposed to generate the same bits, after all???!! > >> I'm not sure why - I'd guess something to do with VARIANT or FILES_m > >> > >> It's highly dubious whether we should have this extremely subtle and > error-prone distinction between release and fastdebug builds at all. > > Thanks for confirming it's old build only, that was my reading too but > without checking. > > > > Anyway, I do consider it a bug (in the old build), and really hard to > track down too until you see both libz and the JDK's libzip loaded. Kelly > might have some insight the product vs. fastdebug difference. > > I have filed many issues over the years asking that mapfiles (or version > scripts) be used to limit the > visibility of extern symbols in Solaris and Linux. Most developers fail to > understand the importance of this. > > I have also always wanted the fastdebug libraries and even debug build > libraries to be 'plug&play' so that they > exported the exact same externs and same prototypes, and could be plopped > into a product build to isolate problems > in just one single library. Unfortunately, some teams have added > additional externs > to the debug versions and that would imply the need for a different > mapfile, so I suspect the easy path was to just > not use a mapfile with the debug builds. It is rare that this is an issue, > but obviously this is a case where it was. > > The policy should be that ALL shared libraries be scoped and only expose > the extern symbols needed. > > However, with the old builds being this way all along, I see no need to go > into the old builds to fix this. > We have so much work to do as it is. > > -kto > > > > > -Alan > > From philip.race at oracle.com Mon Feb 25 21:36:15 2013 From: philip.race at oracle.com (Phil Race) Date: Mon, 25 Feb 2013 13:36:15 -0800 Subject: current clone of jfx is crashing In-Reply-To: <512BD556.8030801@oracle.com> References: <512B98FF.4080206@oracle.com> <512B9ED0.7020900@oracle.com> <512BD556.8030801@oracle.com> Message-ID: <512BD94F.2090103@oracle.com> > Using the jfxrt.jar from 7u15 works OK, but not the one built from the cloned repo. I don't know what Pete cloned .. but JavaFX is a mixture of native and Java, just like JDK and you can't mix and match the jar and the native any more than you could mix rt.jar from 7u13 and native libs from 7u15 and expect it to work. It just takes one small critical change for it all to come "crash"ing down. -phil. On 2/25/2013 1:19 PM, Tim Bell wrote: > Hi Pete: > >> p.s. It fails on Win but not Mac. > > I did some searching on https://jbs.oracle.com/bugs/browse/JDK, but > did not find an open bug report. Maybe I am looking in the wrong bug > tracking system. > > Do you have any contacts in the JavaFX teams? If so, please reach out > to them. I'm not sure how any are on the JDK build list. > > Tim > >> On 2/25/13 11:01 AM, Pete Brunet wrote: >>> The current clone of jfx is crashing when running the HelloButton demo. >>> Upgrading from 7u9 to 7u15 didn't help. Using the jfxrt.jar from 7u15 >>> works OK, but not the one built from the cloned repo. -Pete >>> >>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) >>> >>> # Problematic frame: >>> # V [jvm.dll+0xfb0a1] >>> >>> j com.sun.glass.ui.win.WinApplication._runLoop(Ljava/lang/Runnable;)V+0 >>> j >>> com.sun.glass.ui.win.WinApplication.access$300(Lcom/sun/glass/ui/win/WinApplication;Ljava/lang/Runnable;)V+2 >>> >>> j com.sun.glass.ui.win.WinApplication$3$1.run()V+25 >>> j java.lang.Thread.run()V+11 >>> v ~StubRoutines::call_stub >>> >>> Java Threads: ( => current thread ) >>> =>0x000000000ca2e800 JavaThread "WindowsNativeRunloopThread" >>> [_thread_in_vm, id=6392, stack(0x000000000df40000,0x000000000e040000)] >>> 0x000000000b1b8800 JavaThread "Thread-2" daemon [_thread_blocked, >>> id=3584, stack(0x000000000dd70000,0x000000000de70000)] >>> 0x000000000b249800 JavaThread "QuantumRenderer-0" daemon >>> [_thread_blocked, id=4624, >>> stack(0x000000000cfb0000,0x000000000d0b0000)] >>> 0x000000000b1b4800 JavaThread "JavaFX-Launcher" [_thread_blocked, >>> id=3228, stack(0x000000000cdd0000,0x000000000ced0000)] >>> 0x000000000b19a800 JavaThread "Service Thread" daemon >>> [_thread_blocked, id=3868, >>> stack(0x000000000c6a0000,0x000000000c7a0000)] >>> 0x000000000b197800 JavaThread "C2 CompilerThread1" daemon >>> [_thread_blocked, id=7164, >>> stack(0x000000000c430000,0x000000000c530000)] >>> 0x000000000b189800 JavaThread "C2 CompilerThread0" daemon >>> [_thread_blocked, id=6356, >>> stack(0x000000000c1e0000,0x000000000c2e0000)] >>> 0x000000000b187000 JavaThread "Attach Listener" daemon >>> [_thread_blocked, id=7100, >>> stack(0x000000000c0e0000,0x000000000c1e0000)] >>> 0x000000000b185800 JavaThread "Signal Dispatcher" daemon >>> [_thread_blocked, id=4864, >>> stack(0x000000000bc40000,0x000000000bd40000)] >>> 0x000000000b0ff000 JavaThread "Finalizer" daemon [_thread_blocked, >>> id=4360, stack(0x000000000bfb0000,0x000000000c0b0000)] >>> 0x000000000b0f5000 JavaThread "Reference Handler" daemon >>> [_thread_blocked, id=6668, >>> stack(0x000000000beb0000,0x000000000bfb0000)] >>> 0x0000000001dad000 JavaThread "main" [_thread_blocked, id=3972, >>> stack(0x0000000002420000,0x0000000002520000)] >>> >>> > > From peter.brunet at oracle.com Mon Feb 25 21:40:47 2013 From: peter.brunet at oracle.com (Pete Brunet) Date: Mon, 25 Feb 2013 15:40:47 -0600 Subject: current clone of jfx is crashing In-Reply-To: <512BD94F.2090103@oracle.com> References: <512B98FF.4080206@oracle.com> <512B9ED0.7020900@oracle.com> <512BD556.8030801@oracle.com> <512BD94F.2090103@oracle.com> Message-ID: <512BDA5F.4090602@oracle.com> Thanks Phil, That might be a useful hint. If I use the jfxrt.jar from 7u15 there are no problems but if I use the jfxrt.jar built from the jfx controls scrum repo it fails. I am going to try building from the jfx graphics repo. I don't know much about the jfx build and related dependencies but Kevin might. Pete On 2/25/13 3:36 PM, Phil Race wrote: > > Using the jfxrt.jar from 7u15 works OK, but not the one built from > the cloned repo. > > I don't know what Pete cloned .. but JavaFX is a mixture of native and > Java, just like > JDK and you can't mix and match the jar and the native any more than > you could > mix rt.jar from 7u13 and native libs from 7u15 and expect it to work. > It just takes > one small critical change for it all to come "crash"ing down. > > -phil. > > On 2/25/2013 1:19 PM, Tim Bell wrote: >> Hi Pete: >> >>> p.s. It fails on Win but not Mac. >> >> I did some searching on https://jbs.oracle.com/bugs/browse/JDK, but >> did not find an open bug report. Maybe I am looking in the wrong bug >> tracking system. >> >> Do you have any contacts in the JavaFX teams? If so, please reach >> out to them. I'm not sure how any are on the JDK build list. >> >> Tim >> >>> On 2/25/13 11:01 AM, Pete Brunet wrote: >>>> The current clone of jfx is crashing when running the HelloButton >>>> demo. >>>> Upgrading from 7u9 to 7u15 didn't help. Using the jfxrt.jar from 7u15 >>>> works OK, but not the one built from the cloned repo. -Pete >>>> >>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) >>>> >>>> # Problematic frame: >>>> # V [jvm.dll+0xfb0a1] >>>> >>>> j >>>> com.sun.glass.ui.win.WinApplication._runLoop(Ljava/lang/Runnable;)V+0 >>>> j >>>> com.sun.glass.ui.win.WinApplication.access$300(Lcom/sun/glass/ui/win/WinApplication;Ljava/lang/Runnable;)V+2 >>>> >>>> j com.sun.glass.ui.win.WinApplication$3$1.run()V+25 >>>> j java.lang.Thread.run()V+11 >>>> v ~StubRoutines::call_stub >>>> >>>> Java Threads: ( => current thread ) >>>> =>0x000000000ca2e800 JavaThread "WindowsNativeRunloopThread" >>>> [_thread_in_vm, id=6392, stack(0x000000000df40000,0x000000000e040000)] >>>> 0x000000000b1b8800 JavaThread "Thread-2" daemon [_thread_blocked, >>>> id=3584, stack(0x000000000dd70000,0x000000000de70000)] >>>> 0x000000000b249800 JavaThread "QuantumRenderer-0" daemon >>>> [_thread_blocked, id=4624, >>>> stack(0x000000000cfb0000,0x000000000d0b0000)] >>>> 0x000000000b1b4800 JavaThread "JavaFX-Launcher" [_thread_blocked, >>>> id=3228, stack(0x000000000cdd0000,0x000000000ced0000)] >>>> 0x000000000b19a800 JavaThread "Service Thread" daemon >>>> [_thread_blocked, id=3868, >>>> stack(0x000000000c6a0000,0x000000000c7a0000)] >>>> 0x000000000b197800 JavaThread "C2 CompilerThread1" daemon >>>> [_thread_blocked, id=7164, >>>> stack(0x000000000c430000,0x000000000c530000)] >>>> 0x000000000b189800 JavaThread "C2 CompilerThread0" daemon >>>> [_thread_blocked, id=6356, >>>> stack(0x000000000c1e0000,0x000000000c2e0000)] >>>> 0x000000000b187000 JavaThread "Attach Listener" daemon >>>> [_thread_blocked, id=7100, >>>> stack(0x000000000c0e0000,0x000000000c1e0000)] >>>> 0x000000000b185800 JavaThread "Signal Dispatcher" daemon >>>> [_thread_blocked, id=4864, >>>> stack(0x000000000bc40000,0x000000000bd40000)] >>>> 0x000000000b0ff000 JavaThread "Finalizer" daemon [_thread_blocked, >>>> id=4360, stack(0x000000000bfb0000,0x000000000c0b0000)] >>>> 0x000000000b0f5000 JavaThread "Reference Handler" daemon >>>> [_thread_blocked, id=6668, >>>> stack(0x000000000beb0000,0x000000000bfb0000)] >>>> 0x0000000001dad000 JavaThread "main" [_thread_blocked, id=3972, >>>> stack(0x0000000002420000,0x0000000002520000)] >>>> >>>> >> >> > From martinrb at google.com Mon Feb 25 22:06:54 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 25 Feb 2013 14:06:54 -0800 Subject: New build system problems In-Reply-To: <5129CD25.2000003@oracle.com> References: <5129CD25.2000003@oracle.com> Message-ID: On Sun, Feb 24, 2013 at 12:19 AM, Dmitry Samersoff < dmitry.samersoff at oracle.com> wrote: > > 2. Not all versions of test support == as equation. It's better to use > single one. and I would prefer to have quotes around xmacosx and > xwindows just for consistency. i.e. > > if test "x$OPENJDK_TARGET_OS" = "xwindows"; > Done. From martinrb at google.com Mon Feb 25 22:10:37 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 25 Feb 2013 14:10:37 -0800 Subject: New build system problems In-Reply-To: <5129CD25.2000003@oracle.com> References: <5129CD25.2000003@oracle.com> Message-ID: I'm willing to let someone else on build-dev take over this change, or I can implement some clear policy. It seems reasonable to do: windows => cl solaris => cc gcc anything else => gcc cc With environment variables to allow experimental use of insane^Wunsupported compilers. Do we have consensus on that? Martin On Sun, Feb 24, 2013 at 12:19 AM, Dmitry Samersoff < dmitry.samersoff at oracle.com> wrote: > > 1. for windows compiler checklist become: cl cc gcc > > I'm not sure we need to check for cc on windows, also gcc build on > windows is not supported. So It might be better to be more explicit: > > 256 COMPILER_CHECK_LIST="cc gcc" > # Overriding COMPILER_CHECK_LIST to set OS specific preferences > 257 if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then > 258 # Do not probe for cc on MacOSX. > 259 COMPILER_CHECK_LIST="gcc" > 260 fi > 261 if test "x$OPENJDK_TARGET_OS" = "xwindows"; then > 262 COMPILER_CHECK_LIST="cl" > 263 fi > > > 2. Not all versions of test support == as equation. It's better to use > single one. and I would prefer to have quotes around xmacosx and > xwindows just for consistency. i.e. > > if test "x$OPENJDK_TARGET_OS" = "xwindows"; > > -Dmitry > > > On 2013-02-24 00:05, Martin Buchholz wrote: > > Hi Erik, Tim, Kelly > > > > Here's a proposed fix for you to review: > > > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/COMPILER_CHECK_LIST/ > > > > Martin > > > > On Fri, Jan 25, 2013 at 3:51 PM, Martin Buchholz >wrote: > > > >> I was trying out the shiny new build system. > >> > >> Problem: configure is not executable - must run bash ./configure > >> It's traditional for configure scripts to be executable. > >> > >> Problem: Your life is hell if you have a non-compiler "cl" command on > your > >> PATH, even on Linux. > >> > >> checking for cl... /usr/bin/cl > >> configure: Resolving CC (as /usr/bin/cl) failed, using /usr/bin/cl > >> directly. > >> > >> with subsequent failure to compile. > >> > >> Even if you specify the compiler explicitly, it doesn't help: > >> > >> CC=/usr/bin/gcc CXX=/usr/bin/g++ bash ./configure > >> > >> Of course, one can work around this by creating a "tools dir", but > >> excising the unloved cl from the configure script is tempting and > effective. > >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * Give Rabbit time, and he'll always get the answer > From david.dehaven at oracle.com Mon Feb 25 22:48:37 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 25 Feb 2013 14:48:37 -0800 Subject: current clone of jfx is crashing In-Reply-To: <512BDA5F.4090602@oracle.com> References: <512B98FF.4080206@oracle.com> <512B9ED0.7020900@oracle.com> <512BD556.8030801@oracle.com> <512BD94F.2090103@oracle.com> <512BDA5F.4090602@oracle.com> Message-ID: Make sure the cache you're pulling from is from the matching hudson builds. If controls is out of sync with master, then it's very likely to break and by default the cache is populated with artifacts from master, not the scrum you're working in. For example if you pulled from 8.0-controls-scrum run: ant -Dhudson.jfx.job.name=8.0-controls-scrum update-cache -DrD- > Thanks Phil, That might be a useful hint. If I use the jfxrt.jar from > 7u15 there are no problems but if I use the jfxrt.jar built from the jfx > controls scrum repo it fails. I am going to try building from the jfx > graphics repo. I don't know much about the jfx build and related > dependencies but Kevin might. > > Pete > > On 2/25/13 3:36 PM, Phil Race wrote: >>> Using the jfxrt.jar from 7u15 works OK, but not the one built from >> the cloned repo. >> >> I don't know what Pete cloned .. but JavaFX is a mixture of native and >> Java, just like >> JDK and you can't mix and match the jar and the native any more than >> you could >> mix rt.jar from 7u13 and native libs from 7u15 and expect it to work. >> It just takes >> one small critical change for it all to come "crash"ing down. >> >> -phil. >> >> On 2/25/2013 1:19 PM, Tim Bell wrote: >>> Hi Pete: >>> >>>> p.s. It fails on Win but not Mac. >>> >>> I did some searching on https://jbs.oracle.com/bugs/browse/JDK, but >>> did not find an open bug report. Maybe I am looking in the wrong bug >>> tracking system. >>> >>> Do you have any contacts in the JavaFX teams? If so, please reach >>> out to them. I'm not sure how any are on the JDK build list. >>> >>> Tim >>> >>>> On 2/25/13 11:01 AM, Pete Brunet wrote: >>>>> The current clone of jfx is crashing when running the HelloButton >>>>> demo. >>>>> Upgrading from 7u9 to 7u15 didn't help. Using the jfxrt.jar from 7u15 >>>>> works OK, but not the one built from the cloned repo. -Pete >>>>> >>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) >>>>> >>>>> # Problematic frame: >>>>> # V [jvm.dll+0xfb0a1] >>>>> >>>>> j >>>>> com.sun.glass.ui.win.WinApplication._runLoop(Ljava/lang/Runnable;)V+0 >>>>> j >>>>> com.sun.glass.ui.win.WinApplication.access$300(Lcom/sun/glass/ui/win/WinApplication;Ljava/lang/Runnable;)V+2 >>>>> >>>>> j com.sun.glass.ui.win.WinApplication$3$1.run()V+25 >>>>> j java.lang.Thread.run()V+11 >>>>> v ~StubRoutines::call_stub >>>>> >>>>> Java Threads: ( => current thread ) >>>>> =>0x000000000ca2e800 JavaThread "WindowsNativeRunloopThread" >>>>> [_thread_in_vm, id=6392, stack(0x000000000df40000,0x000000000e040000)] >>>>> 0x000000000b1b8800 JavaThread "Thread-2" daemon [_thread_blocked, >>>>> id=3584, stack(0x000000000dd70000,0x000000000de70000)] >>>>> 0x000000000b249800 JavaThread "QuantumRenderer-0" daemon >>>>> [_thread_blocked, id=4624, >>>>> stack(0x000000000cfb0000,0x000000000d0b0000)] >>>>> 0x000000000b1b4800 JavaThread "JavaFX-Launcher" [_thread_blocked, >>>>> id=3228, stack(0x000000000cdd0000,0x000000000ced0000)] >>>>> 0x000000000b19a800 JavaThread "Service Thread" daemon >>>>> [_thread_blocked, id=3868, >>>>> stack(0x000000000c6a0000,0x000000000c7a0000)] >>>>> 0x000000000b197800 JavaThread "C2 CompilerThread1" daemon >>>>> [_thread_blocked, id=7164, >>>>> stack(0x000000000c430000,0x000000000c530000)] >>>>> 0x000000000b189800 JavaThread "C2 CompilerThread0" daemon >>>>> [_thread_blocked, id=6356, >>>>> stack(0x000000000c1e0000,0x000000000c2e0000)] >>>>> 0x000000000b187000 JavaThread "Attach Listener" daemon >>>>> [_thread_blocked, id=7100, >>>>> stack(0x000000000c0e0000,0x000000000c1e0000)] >>>>> 0x000000000b185800 JavaThread "Signal Dispatcher" daemon >>>>> [_thread_blocked, id=4864, >>>>> stack(0x000000000bc40000,0x000000000bd40000)] >>>>> 0x000000000b0ff000 JavaThread "Finalizer" daemon [_thread_blocked, >>>>> id=4360, stack(0x000000000bfb0000,0x000000000c0b0000)] >>>>> 0x000000000b0f5000 JavaThread "Reference Handler" daemon >>>>> [_thread_blocked, id=6668, >>>>> stack(0x000000000beb0000,0x000000000bfb0000)] >>>>> 0x0000000001dad000 JavaThread "main" [_thread_blocked, id=3972, >>>>> stack(0x0000000002420000,0x0000000002520000)] >>>>> >>>>> >>> >>> >> > From jonathan.gibbons at oracle.com Mon Feb 25 22:53:10 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 25 Feb 2013 14:53:10 -0800 Subject: type in NewMakefile.gmk Message-ID: <512BEB56.2090200@oracle.com> # Run the makefile with an arbitraty SPEC From tim.bell at oracle.com Tue Feb 26 00:20:44 2013 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 25 Feb 2013 16:20:44 -0800 Subject: type in NewMakefile.gmk In-Reply-To: <512BEB56.2090200@oracle.com> References: <512BEB56.2090200@oracle.com> Message-ID: <512BFFDC.1020409@oracle.com> On 02/25/13 14:53, Jonathan Gibbons wrote: > # Run the makefile with an arbitraty SPEC Thanks, Jon I filed JDK-8008944 "build-infra: clean up typos" so we don't lose track of these. Feel free to add any more you come across. Tim From david.holmes at oracle.com Tue Feb 26 07:24:27 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Feb 2013 17:24:27 +1000 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> Message-ID: <512C632B.3070206@oracle.com> On 26/02/2013 4:42 AM, Christian Thalinger wrote: > On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>> >>> http://cr.openjdk.java.net/~twisti/8006965/ >>> >>> This would be the first of three fixes: >>> >>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >> >> This logic is not suitable: >> >> 541 # Testing the built JVM >> 542 ifeq ($(JAVA_HOME),) >> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >> 544 else >> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >> 546 endif >> >> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! > > That's not entirely correct. test_gamma uses your JAVA_HOME setting: This is so confusing. Our makefiles are an abomination! So this all started because the makefile has: JAVA_HOME=$(ABS_BOOTDIR) which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. So how did the boot JDK come back into this??? > cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 > cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma > Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre > > cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo > cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma > JAVA_HOME must point to a 64-bit OpenJDK. > > And here comes this little snippet into play: > > -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) > +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) > > Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? Thanks, David > I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. > >> >> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? > > It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. > >> >> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. > > It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. > > -- Chris > >> >> And this addition still makes no sense to me: >> >> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >> >> Why do you need to add BOOTDIR to the MAKE_ARGS? >> >> David >> >> >>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>> >>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>> >>> -- Chris >>> >>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>> >>>> >>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>> >>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>> >>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>> >>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>> >>>> -- Chris >>>> >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>> >>>>>> 8006965: test_gamma should run with import JDK >>>>>> Reviewed-by: >>>>>> >>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>> >>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>> running test_gamma. >>>>>> >>>>>> make/bsd/makefiles/buildtree.make >>>>>> make/defs.make >>>>>> make/linux/makefiles/buildtree.make >>>>>> make/solaris/makefiles/buildtree.make >>>>>> >>>>> >>>> >>> > From staffan.larsen at oracle.com Tue Feb 26 09:05:20 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 26 Feb 2013 10:05:20 +0100 Subject: How to re-run configure? Message-ID: <424553D3-E254-4896-BB5D-E348B28EA543@oracle.com> Is there a shorthand for re-running configure on one of my configurations without having to re-type the configure arguments I used when creating the configuration? I have a number of configurations and when I have to re-run configure, I have to both specify the correct --with-conf-name and then the correct configure options I used last time. I know I can find those in the configure-arguments file. What I would like is something simliar to "make CONF=..." but for configure: "sh configure CONF=...". Thanks, /Staffan From dmitry.samersoff at oracle.com Tue Feb 26 13:43:25 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 26 Feb 2013 17:43:25 +0400 Subject: New build system problems In-Reply-To: References: <5129CD25.2000003@oracle.com> Message-ID: <512CBBFD.5050001@oracle.com> Martin, On 2013-02-26 02:10, Martin Buchholz wrote: > I'm willing to let someone else on build-dev take over this change, or I > can implement some clear policy. > It seems reasonable to do: > > windows => cl > solaris => cc gcc > anything else => gcc cc > > With environment variables to allow experimental use of > insane^Wunsupported compilers. > > Do we have consensus on that? Sounds good for me. -Dmitry > > Martin > > On Sun, Feb 24, 2013 at 12:19 AM, Dmitry Samersoff > > wrote: > > > 1. for windows compiler checklist become: cl cc gcc > > I'm not sure we need to check for cc on windows, also gcc build on > windows is not supported. So It might be better to be more explicit: > > 256 COMPILER_CHECK_LIST="cc gcc" > # Overriding COMPILER_CHECK_LIST to set OS specific preferences > 257 if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then > 258 # Do not probe for cc on MacOSX. > 259 COMPILER_CHECK_LIST="gcc" > 260 fi > 261 if test "x$OPENJDK_TARGET_OS" = "xwindows"; then > 262 COMPILER_CHECK_LIST="cl" > 263 fi > > > 2. Not all versions of test support == as equation. It's better to use > single one. and I would prefer to have quotes around xmacosx and > xwindows just for consistency. i.e. > > if test "x$OPENJDK_TARGET_OS" = "xwindows"; > > -Dmitry > > > On 2013-02-24 00:05, Martin Buchholz wrote: > > Hi Erik, Tim, Kelly > > > > Here's a proposed fix for you to review: > > > > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/COMPILER_CHECK_LIST/ > > > > Martin > > > > On Fri, Jan 25, 2013 at 3:51 PM, Martin Buchholz > >wrote: > > > >> I was trying out the shiny new build system. > >> > >> Problem: configure is not executable - must run bash ./configure > >> It's traditional for configure scripts to be executable. > >> > >> Problem: Your life is hell if you have a non-compiler "cl" > command on your > >> PATH, even on Linux. > >> > >> checking for cl... /usr/bin/cl > >> configure: Resolving CC (as /usr/bin/cl) failed, using /usr/bin/cl > >> directly. > >> > >> with subsequent failure to compile. > >> > >> Even if you specify the compiler explicitly, it doesn't help: > >> > >> CC=/usr/bin/gcc CXX=/usr/bin/g++ bash ./configure > >> > >> Of course, one can work around this by creating a "tools dir", but > >> excising the unloved cl from the configure script is tempting and > effective. > >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * Give Rabbit time, and he'll always get the answer > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From Alan.Bateman at oracle.com Tue Feb 26 13:48:07 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Feb 2013 13:48:07 +0000 Subject: 8008977: profiles build broken by Nashorn build changes Message-ID: <512CBD17.8090808@oracle.com> The build changes for Nashorn were pushed to jdk8/tl yesterday and one of the casualties is the profiles build. My reading of the make file changes is that ListPathsSafely_If (defined in MakeBase.gmk) has changed the expansion so that secondary expansion is no longer required. Erik is away this week but I assume this was intentional. Attached is the diffs that I propose to push to jdk8/tl today to get profiles building again, assuming I get a reviewer. -Alan diff --git a/makefiles/profile-rtjar-includes.txt b/makefiles/profile-rtjar-includes.txt --- a/makefiles/profile-rtjar-includes.txt +++ b/makefiles/profile-rtjar-includes.txt @@ -349,6 +349,7 @@ com/sun/rowset/providers \ com/sun/script/javascript \ com/sun/script/util \ + com/sun/security/auth \ com/sun/security/auth/callback \ com/sun/security/auth/login \ com/sun/security/auth/module \ @@ -448,8 +449,7 @@ sun/tracing \ sun/tracing/dtrace -PROFILE_3_RTJAR_INCLUDE_TYPES := \ - com/sun/security/auth/*.class +PROFILE_3_RTJAR_INCLUDE_TYPES := PROFILE_3_RTJAR_EXCLUDE_TYPES := \ javax/management/remote/rmi/_RMIConnectionImpl_Tie.class \ @@ -457,10 +457,10 @@ javax/management/remote/rmi/_RMIServerImpl_Tie.class \ javax/management/remote/rmi/_RMIServer_Stub.class \ com/sun/security/auth/callback/DialogCallbackHandler.class \ - com/sun/security/auth/callback/DialogCallbackHandler\$$$$1.class \ - com/sun/security/auth/callback/DialogCallbackHandler\$$$$2.class \ - com/sun/security/auth/callback/DialogCallbackHandler\$$$$Action.class \ - com/sun/security/auth/callback/DialogCallbackHandler\$$$$ConfirmationInfo.class + com/sun/security/auth/callback/DialogCallbackHandler\$$1.class \ + com/sun/security/auth/callback/DialogCallbackHandler\$$2.class \ + com/sun/security/auth/callback/DialogCallbackHandler\$$Action.class \ + com/sun/security/auth/callback/DialogCallbackHandler\$$ConfirmationInfo.class PROFILE_3_INCLUDE_METAINF_SERVICES := \ META-INF/services/javax.script.ScriptEngineFactory From Alan.Bateman at oracle.com Tue Feb 26 13:52:10 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Feb 2013 13:52:10 +0000 Subject: 8008978: nashorn-rules.gmk missing Message-ID: <512CBE0A.2040203@oracle.com> While looking at the Nashorn build changes, I see that /make/nashorn-rules.gmk is included by the top-level Makefile but was missed in the change-set. I checked with Jim Laskey and it he sent me the missing .gmk which I've put here: http://cr.openjdk.java.net/~alanb/8008978/webrev/ I plan to push this jdk8/tl today. -Alan. From dmitry.samersoff at oracle.com Tue Feb 26 13:53:52 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 26 Feb 2013 17:53:52 +0400 Subject: How to re-run configure? In-Reply-To: <424553D3-E254-4896-BB5D-E348B28EA543@oracle.com> References: <424553D3-E254-4896-BB5D-E348B28EA543@oracle.com> Message-ID: <512CBE70.5000806@oracle.com> Staffan, 1. Keep config.log somewhere 2. Attached script or something similar will do the trick -Dmitry On 2013-02-26 13:05, Staffan Larsen wrote: > Is there a shorthand for re-running configure on one of my > configurations without having to re-type the configure arguments I > used when creating the configuration? > > I have a number of configurations and when I have to re-run > configure, I have to both specify the correct --with-conf-name and > then the correct configure options I used last time. I know I can > find those in the configure-arguments file. > > What I would like is something simliar to "make CONF=..." but for > configure: "sh configure CONF=...". > > Thanks, /Staffan > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer -------------- next part -------------- rr=`cat config.log| sed -n /configure/s at .*autoconf/configure at ./configure at p` sh ${rr} From chris.hegarty at oracle.com Tue Feb 26 14:05:19 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 26 Feb 2013 14:05:19 +0000 Subject: 8008977: profiles build broken by Nashorn build changes In-Reply-To: <512CBD17.8090808@oracle.com> References: <512CBD17.8090808@oracle.com> Message-ID: <512CC11F.5040505@oracle.com> On 02/26/2013 01:48 PM, Alan Bateman wrote: > > The build changes for Nashorn were pushed to jdk8/tl yesterday and one > of the casualties is the profiles build. > > My reading of the make file changes is that ListPathsSafely_If (defined > in MakeBase.gmk) has changed the expansion so that secondary expansion > is no longer required. Erik is away this week but I assume this was > intentional. If this is the case, then your changes look fine to me. If not, then it can be revisited later, if required. -Chris. > > Attached is the diffs that I propose to push to jdk8/tl today to get > profiles building again, assuming I get a reviewer. > > -Alan > > > diff --git a/makefiles/profile-rtjar-includes.txt > b/makefiles/profile-rtjar-includes.txt > --- a/makefiles/profile-rtjar-includes.txt > +++ b/makefiles/profile-rtjar-includes.txt > @@ -349,6 +349,7 @@ > com/sun/rowset/providers \ > com/sun/script/javascript \ > com/sun/script/util \ > + com/sun/security/auth \ > com/sun/security/auth/callback \ > com/sun/security/auth/login \ > com/sun/security/auth/module \ > @@ -448,8 +449,7 @@ > sun/tracing \ > sun/tracing/dtrace > > -PROFILE_3_RTJAR_INCLUDE_TYPES := \ > - com/sun/security/auth/*.class > +PROFILE_3_RTJAR_INCLUDE_TYPES := > > PROFILE_3_RTJAR_EXCLUDE_TYPES := \ > javax/management/remote/rmi/_RMIConnectionImpl_Tie.class \ > @@ -457,10 +457,10 @@ > javax/management/remote/rmi/_RMIServerImpl_Tie.class \ > javax/management/remote/rmi/_RMIServer_Stub.class \ > com/sun/security/auth/callback/DialogCallbackHandler.class \ > - com/sun/security/auth/callback/DialogCallbackHandler\$$$$1.class \ > - com/sun/security/auth/callback/DialogCallbackHandler\$$$$2.class \ > - > com/sun/security/auth/callback/DialogCallbackHandler\$$$$Action.class \ > - > com/sun/security/auth/callback/DialogCallbackHandler\$$$$ConfirmationInfo.class > > + com/sun/security/auth/callback/DialogCallbackHandler\$$1.class \ > + com/sun/security/auth/callback/DialogCallbackHandler\$$2.class \ > + com/sun/security/auth/callback/DialogCallbackHandler\$$Action.class \ > + > com/sun/security/auth/callback/DialogCallbackHandler\$$ConfirmationInfo.class > > > PROFILE_3_INCLUDE_METAINF_SERVICES := \ > META-INF/services/javax.script.ScriptEngineFactory From staffan.larsen at oracle.com Tue Feb 26 14:05:43 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 26 Feb 2013 15:05:43 +0100 Subject: How to re-run configure? In-Reply-To: <512CBE70.5000806@oracle.com> References: <424553D3-E254-4896-BB5D-E348B28EA543@oracle.com> <512CBE70.5000806@oracle.com> Message-ID: <6778CFAD-CAD1-4F67-9F37-1272C2A60F58@oracle.com> Thanks Dmitry, I was looking for a standard way of doing this. While a custom script helps, it would be nice to have the support in the source. /Staffan On 26 feb 2013, at 14:53, Dmitry Samersoff wrote: > Staffan, > > 1. Keep config.log somewhere > 2. Attached script or something similar will do the trick > > -Dmitry > > On 2013-02-26 13:05, Staffan Larsen wrote: >> Is there a shorthand for re-running configure on one of my >> configurations without having to re-type the configure arguments I >> used when creating the configuration? >> >> I have a number of configurations and when I have to re-run >> configure, I have to both specify the correct --with-conf-name and >> then the correct configure options I used last time. I know I can >> find those in the configure-arguments file. >> >> What I would like is something simliar to "make CONF=..." but for >> configure: "sh configure CONF=...". >> >> Thanks, /Staffan >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * Give Rabbit time, and he'll always get the answer > From chris.hegarty at oracle.com Tue Feb 26 14:10:36 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 26 Feb 2013 14:10:36 +0000 Subject: 8008978: nashorn-rules.gmk missing In-Reply-To: <512CBE0A.2040203@oracle.com> References: <512CBE0A.2040203@oracle.com> Message-ID: <512CC25C.8050108@oracle.com> On 02/26/2013 01:52 PM, Alan Bateman wrote: > > While looking at the Nashorn build changes, I see that > /make/nashorn-rules.gmk is included by the top-level Makefile but > was missed in the change-set. Wow, a whole missing rules file! I'm surprised this wasn't caught during build and testing. > I checked with Jim Laskey and it he sent me the missing .gmk which I've > put here: > > http://cr.openjdk.java.net/~alanb/8008978/webrev/ The copyright year range seems a little odd, but that is a minor point. Consider is reviewed. -Chris. > > I plan to push this jdk8/tl today. > > -Alan. From Alan.Bateman at oracle.com Tue Feb 26 14:25:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Feb 2013 14:25:17 +0000 Subject: 8008978: nashorn-rules.gmk missing In-Reply-To: <512CC25C.8050108@oracle.com> References: <512CBE0A.2040203@oracle.com> <512CC25C.8050108@oracle.com> Message-ID: <512CC5CD.2030202@oracle.com> On 26/02/2013 14:10, Chris Hegarty wrote: > On 02/26/2013 01:52 PM, Alan Bateman wrote: >> >> While looking at the Nashorn build changes, I see that >> /make/nashorn-rules.gmk is included by the top-level Makefile but >> was missed in the change-set. > > Wow, a whole missing rules file! I'm surprised this wasn't caught > during build and testing. It doesn't actually effect the build, but it just mean that some nashorn targets are missing. I only noticed it while looking at another build failure. -Alan. From peter.brunet at oracle.com Tue Feb 26 14:51:35 2013 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 26 Feb 2013 08:51:35 -0600 Subject: current clone of jfx is crashing In-Reply-To: <512BDA5F.4090602@oracle.com> References: <512B98FF.4080206@oracle.com> <512B9ED0.7020900@oracle.com> <512BD556.8030801@oracle.com> <512BD94F.2090103@oracle.com> <512BDA5F.4090602@oracle.com> Message-ID: <512CCBF7.30006@oracle.com> I've been informed that this was not the right list to post this issue to (not a JDK build issue) but since then I've solved the problem and am posting the following information for anyone on the list that might benefit from it... The problem was that I was using 64 bit Java instead of 32 bit Java to run the JavaFX HelloWorld NetBeans project. I had previously set my HelloWorId project properties to point to a 32 bit Java and maybe last Friday's hg pull -u reset my NB setup for that project back to specifying the Default installation of Java. I updated my etc\netbeans.conf file to point at a 32 bit Java and reset the HelloWorld project properties back to specifying the Default version of Java. That config is working OK so this should insulate me from this problem in the future. Pete On 2/25/13 3:40 PM, Pete Brunet wrote: > Thanks Phil, That might be a useful hint. If I use the jfxrt.jar from > 7u15 there are no problems but if I use the jfxrt.jar built from the jfx > controls scrum repo it fails. I am going to try building from the jfx > graphics repo. I don't know much about the jfx build and related > dependencies but Kevin might. > > Pete > > On 2/25/13 3:36 PM, Phil Race wrote: >>> Using the jfxrt.jar from 7u15 works OK, but not the one built from >> the cloned repo. >> >> I don't know what Pete cloned .. but JavaFX is a mixture of native and >> Java, just like >> JDK and you can't mix and match the jar and the native any more than >> you could >> mix rt.jar from 7u13 and native libs from 7u15 and expect it to work. >> It just takes >> one small critical change for it all to come "crash"ing down. >> >> -phil. >> >> On 2/25/2013 1:19 PM, Tim Bell wrote: >>> Hi Pete: >>> >>>> p.s. It fails on Win but not Mac. >>> I did some searching on https://jbs.oracle.com/bugs/browse/JDK, but >>> did not find an open bug report. Maybe I am looking in the wrong bug >>> tracking system. >>> >>> Do you have any contacts in the JavaFX teams? If so, please reach >>> out to them. I'm not sure how any are on the JDK build list. >>> >>> Tim >>> >>>> On 2/25/13 11:01 AM, Pete Brunet wrote: >>>>> The current clone of jfx is crashing when running the HelloButton >>>>> demo. >>>>> Upgrading from 7u9 to 7u15 didn't help. Using the jfxrt.jar from 7u15 >>>>> works OK, but not the one built from the cloned repo. -Pete >>>>> >>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) >>>>> >>>>> # Problematic frame: >>>>> # V [jvm.dll+0xfb0a1] >>>>> >>>>> j >>>>> com.sun.glass.ui.win.WinApplication._runLoop(Ljava/lang/Runnable;)V+0 >>>>> j >>>>> com.sun.glass.ui.win.WinApplication.access$300(Lcom/sun/glass/ui/win/WinApplication;Ljava/lang/Runnable;)V+2 >>>>> >>>>> j com.sun.glass.ui.win.WinApplication$3$1.run()V+25 >>>>> j java.lang.Thread.run()V+11 >>>>> v ~StubRoutines::call_stub >>>>> >>>>> Java Threads: ( => current thread ) >>>>> =>0x000000000ca2e800 JavaThread "WindowsNativeRunloopThread" >>>>> [_thread_in_vm, id=6392, stack(0x000000000df40000,0x000000000e040000)] >>>>> 0x000000000b1b8800 JavaThread "Thread-2" daemon [_thread_blocked, >>>>> id=3584, stack(0x000000000dd70000,0x000000000de70000)] >>>>> 0x000000000b249800 JavaThread "QuantumRenderer-0" daemon >>>>> [_thread_blocked, id=4624, >>>>> stack(0x000000000cfb0000,0x000000000d0b0000)] >>>>> 0x000000000b1b4800 JavaThread "JavaFX-Launcher" [_thread_blocked, >>>>> id=3228, stack(0x000000000cdd0000,0x000000000ced0000)] >>>>> 0x000000000b19a800 JavaThread "Service Thread" daemon >>>>> [_thread_blocked, id=3868, >>>>> stack(0x000000000c6a0000,0x000000000c7a0000)] >>>>> 0x000000000b197800 JavaThread "C2 CompilerThread1" daemon >>>>> [_thread_blocked, id=7164, >>>>> stack(0x000000000c430000,0x000000000c530000)] >>>>> 0x000000000b189800 JavaThread "C2 CompilerThread0" daemon >>>>> [_thread_blocked, id=6356, >>>>> stack(0x000000000c1e0000,0x000000000c2e0000)] >>>>> 0x000000000b187000 JavaThread "Attach Listener" daemon >>>>> [_thread_blocked, id=7100, >>>>> stack(0x000000000c0e0000,0x000000000c1e0000)] >>>>> 0x000000000b185800 JavaThread "Signal Dispatcher" daemon >>>>> [_thread_blocked, id=4864, >>>>> stack(0x000000000bc40000,0x000000000bd40000)] >>>>> 0x000000000b0ff000 JavaThread "Finalizer" daemon [_thread_blocked, >>>>> id=4360, stack(0x000000000bfb0000,0x000000000c0b0000)] >>>>> 0x000000000b0f5000 JavaThread "Reference Handler" daemon >>>>> [_thread_blocked, id=6668, >>>>> stack(0x000000000beb0000,0x000000000bfb0000)] >>>>> 0x0000000001dad000 JavaThread "main" [_thread_blocked, id=3972, >>>>> stack(0x0000000002420000,0x0000000002520000)] >>>>> >>>>> From david.dehaven at oracle.com Tue Feb 26 15:31:13 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 26 Feb 2013 07:31:13 -0800 Subject: How to re-run configure? In-Reply-To: <6778CFAD-CAD1-4F67-9F37-1272C2A60F58@oracle.com> References: <424553D3-E254-4896-BB5D-E348B28EA543@oracle.com> <512CBE70.5000806@oracle.com> <6778CFAD-CAD1-4F67-9F37-1272C2A60F58@oracle.com> Message-ID: <1193BF01-2E57-4E5C-882B-389E0F00A010@oracle.com> build//config.status --recheck -DrD- > Thanks Dmitry, > > I was looking for a standard way of doing this. While a custom script helps, it would be nice to have the support in the source. > > /Staffan > > On 26 feb 2013, at 14:53, Dmitry Samersoff wrote: > >> Staffan, >> >> 1. Keep config.log somewhere >> 2. Attached script or something similar will do the trick >> >> -Dmitry >> >> On 2013-02-26 13:05, Staffan Larsen wrote: >>> Is there a shorthand for re-running configure on one of my >>> configurations without having to re-type the configure arguments I >>> used when creating the configuration? >>> >>> I have a number of configurations and when I have to re-run >>> configure, I have to both specify the correct --with-conf-name and >>> then the correct configure options I used last time. I know I can >>> find those in the configure-arguments file. >>> >>> What I would like is something simliar to "make CONF=..." but for >>> configure: "sh configure CONF=...". >>> >>> Thanks, /Staffan >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * Give Rabbit time, and he'll always get the answer >> > From staffan.larsen at oracle.com Tue Feb 26 18:06:53 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 26 Feb 2013 19:06:53 +0100 Subject: How to re-run configure? In-Reply-To: <1193BF01-2E57-4E5C-882B-389E0F00A010@oracle.com> References: <424553D3-E254-4896-BB5D-E348B28EA543@oracle.com> <512CBE70.5000806@oracle.com> <6778CFAD-CAD1-4F67-9F37-1272C2A60F58@oracle.com> <1193BF01-2E57-4E5C-882B-389E0F00A010@oracle.com> Message-ID: <1C7668AC-7892-4496-9ED1-A70C4072EFDC@oracle.com> Awsome! Thanks, /Staffan On 26 feb 2013, at 16:31, David DeHaven wrote: > > build//config.status --recheck > > -DrD- > >> Thanks Dmitry, >> >> I was looking for a standard way of doing this. While a custom script helps, it would be nice to have the support in the source. >> >> /Staffan >> >> On 26 feb 2013, at 14:53, Dmitry Samersoff wrote: >> >>> Staffan, >>> >>> 1. Keep config.log somewhere >>> 2. Attached script or something similar will do the trick >>> >>> -Dmitry >>> >>> On 2013-02-26 13:05, Staffan Larsen wrote: >>>> Is there a shorthand for re-running configure on one of my >>>> configurations without having to re-type the configure arguments I >>>> used when creating the configuration? >>>> >>>> I have a number of configurations and when I have to re-run >>>> configure, I have to both specify the correct --with-conf-name and >>>> then the correct configure options I used last time. I know I can >>>> find those in the configure-arguments file. >>>> >>>> What I would like is something simliar to "make CONF=..." but for >>>> configure: "sh configure CONF=...". >>>> >>>> Thanks, /Staffan >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * Give Rabbit time, and he'll always get the answer >>> >> > From david.dehaven at oracle.com Tue Feb 26 18:44:13 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 26 Feb 2013 10:44:13 -0800 Subject: How to re-run configure? In-Reply-To: <1C7668AC-7892-4496-9ED1-A70C4072EFDC@oracle.com> References: <424553D3-E254-4896-BB5D-E348B28EA543@oracle.com> <512CBE70.5000806@oracle.com> <6778CFAD-CAD1-4F67-9F37-1272C2A60F58@oracle.com> <1193BF01-2E57-4E5C-882B-389E0F00A010@oracle.com> <1C7668AC-7892-4496-9ED1-A70C4072EFDC@oracle.com> Message-ID: <8AA0E10B-6B2E-47AF-AE61-1B0112CAEA10@oracle.com> config.status does other things too, it's quite handy. -DrD- > Awsome! > > Thanks, > /Staffan > > On 26 feb 2013, at 16:31, David DeHaven wrote: > >> >> build//config.status --recheck >> >> -DrD- >> >>> Thanks Dmitry, >>> >>> I was looking for a standard way of doing this. While a custom script helps, it would be nice to have the support in the source. >>> >>> /Staffan >>> >>> On 26 feb 2013, at 14:53, Dmitry Samersoff wrote: >>> >>>> Staffan, >>>> >>>> 1. Keep config.log somewhere >>>> 2. Attached script or something similar will do the trick >>>> >>>> -Dmitry >>>> >>>> On 2013-02-26 13:05, Staffan Larsen wrote: >>>>> Is there a shorthand for re-running configure on one of my >>>>> configurations without having to re-type the configure arguments I >>>>> used when creating the configuration? >>>>> >>>>> I have a number of configurations and when I have to re-run >>>>> configure, I have to both specify the correct --with-conf-name and >>>>> then the correct configure options I used last time. I know I can >>>>> find those in the configure-arguments file. >>>>> >>>>> What I would like is something simliar to "make CONF=..." but for >>>>> configure: "sh configure CONF=...". >>>>> >>>>> Thanks, /Staffan >>>>> >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * Give Rabbit time, and he'll always get the answer >>>> >>> >> > From Alan.Bateman at oracle.com Tue Feb 26 19:55:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Feb 2013 19:55:49 +0000 Subject: 8009029: SunEC provider classes ending up in rt.jar after Nashorn build changes Message-ID: <512D1345.5060004@oracle.com> I ran into another issue cause from Nashorn build changes, also secondary expansion related. The issue is that some classes are going into rt.jar that shouldn't be there, particularly the SunEC provider, some charset classes too. I would like to push the attached patch to jdk8/tl to fix these issue. -Alan diff --git a/makefiles/CreateJars.gmk b/makefiles/CreateJars.gmk --- a/makefiles/CreateJars.gmk +++ b/makefiles/CreateJars.gmk @@ -213,28 +213,28 @@ org/relaxng/datatype \ sun/awt/HKSCS.class \ sun/awt/motif/X11GB2312.class \ - sun/awt/motif/X11GB2312\$$$$Decoder.class \ - sun/awt/motif/X11GB2312\$$$$Encoder.class \ + sun/awt/motif/X11GB2312\$$Decoder.class \ + sun/awt/motif/X11GB2312\$$Encoder.class \ sun/awt/motif/X11GBK.class \ - sun/awt/motif/X11GBK\$$$$Encoder.class \ + sun/awt/motif/X11GBK\$$Encoder.class \ sun/awt/motif/X11KSC5601.class \ - sun/awt/motif/X11KSC5601\$$$$Decoder.class \ - sun/awt/motif/X11KSC5601\$$$$Encoder.class \ + sun/awt/motif/X11KSC5601\$$Decoder.class \ + sun/awt/motif/X11KSC5601\$$Encoder.class \ sun/jvmstat \ sun/net/spi/nameservice/dns \ sun/nio/cs/ext \ sun/rmi/rmic \ sun/security/ec/ECDHKeyAgreement.class \ sun/security/ec/ECDSASignature.class \ - sun/security/ec/ECDSASignature\$$$$Raw.class \ - sun/security/ec/ECDSASignature\$$$$SHA1.class \ - sun/security/ec/ECDSASignature\$$$$SHA224.class \ - sun/security/ec/ECDSASignature\$$$$SHA256.class \ - sun/security/ec/ECDSASignature\$$$$SHA384.class \ - sun/security/ec/ECDSASignature\$$$$SHA512.class \ + sun/security/ec/ECDSASignature\$$Raw.class \ + sun/security/ec/ECDSASignature\$$SHA1.class \ + sun/security/ec/ECDSASignature\$$SHA224.class \ + sun/security/ec/ECDSASignature\$$SHA256.class \ + sun/security/ec/ECDSASignature\$$SHA384.class \ + sun/security/ec/ECDSASignature\$$SHA512.class \ sun/security/ec/ECKeyFactory.class \ sun/security/ec/ECKeyPairGenerator.class \ - sun/security/ec/SunEC\$$$$1.class \ + sun/security/ec/SunEC\$$1.class \ sun/security/ec/SunEC.class \ sun/security/ec/SunECEntries.class \ sun/security/internal \ From david.holmes at oracle.com Tue Feb 26 20:29:02 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Feb 2013 06:29:02 +1000 Subject: 8008977: profiles build broken by Nashorn build changes In-Reply-To: <512CBD17.8090808@oracle.com> References: <512CBD17.8090808@oracle.com> Message-ID: <512D1B0E.3000309@oracle.com> Alan, Thanks for diving onto this. I can't say I understand what changed in detail yet but I know that there are places where I had to jump through hoops to deal with $ in class names appropriately. I would not be surprised if there is further breakage if somehow this expansion mechanism has changed. David On 26/02/2013 11:48 PM, Alan Bateman wrote: > > The build changes for Nashorn were pushed to jdk8/tl yesterday and one > of the casualties is the profiles build. > > My reading of the make file changes is that ListPathsSafely_If (defined > in MakeBase.gmk) has changed the expansion so that secondary expansion > is no longer required. Erik is away this week but I assume this was > intentional. > > Attached is the diffs that I propose to push to jdk8/tl today to get > profiles building again, assuming I get a reviewer. > > -Alan > > > diff --git a/makefiles/profile-rtjar-includes.txt > b/makefiles/profile-rtjar-includes.txt > --- a/makefiles/profile-rtjar-includes.txt > +++ b/makefiles/profile-rtjar-includes.txt > @@ -349,6 +349,7 @@ > com/sun/rowset/providers \ > com/sun/script/javascript \ > com/sun/script/util \ > + com/sun/security/auth \ > com/sun/security/auth/callback \ > com/sun/security/auth/login \ > com/sun/security/auth/module \ > @@ -448,8 +449,7 @@ > sun/tracing \ > sun/tracing/dtrace > > -PROFILE_3_RTJAR_INCLUDE_TYPES := \ > - com/sun/security/auth/*.class > +PROFILE_3_RTJAR_INCLUDE_TYPES := > > PROFILE_3_RTJAR_EXCLUDE_TYPES := \ > javax/management/remote/rmi/_RMIConnectionImpl_Tie.class \ > @@ -457,10 +457,10 @@ > javax/management/remote/rmi/_RMIServerImpl_Tie.class \ > javax/management/remote/rmi/_RMIServer_Stub.class \ > com/sun/security/auth/callback/DialogCallbackHandler.class \ > - com/sun/security/auth/callback/DialogCallbackHandler\$$$$1.class \ > - com/sun/security/auth/callback/DialogCallbackHandler\$$$$2.class \ > - > com/sun/security/auth/callback/DialogCallbackHandler\$$$$Action.class \ > - > com/sun/security/auth/callback/DialogCallbackHandler\$$$$ConfirmationInfo.class > > + com/sun/security/auth/callback/DialogCallbackHandler\$$1.class \ > + com/sun/security/auth/callback/DialogCallbackHandler\$$2.class \ > + com/sun/security/auth/callback/DialogCallbackHandler\$$Action.class \ > + > com/sun/security/auth/callback/DialogCallbackHandler\$$ConfirmationInfo.class > > > PROFILE_3_INCLUDE_METAINF_SERVICES := \ > META-INF/services/javax.script.ScriptEngineFactory From dmitry.samersoff at oracle.com Tue Feb 26 20:31:48 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 27 Feb 2013 00:31:48 +0400 Subject: How to re-run configure? In-Reply-To: <8AA0E10B-6B2E-47AF-AE61-1B0112CAEA10@oracle.com> References: <424553D3-E254-4896-BB5D-E348B28EA543@oracle.com> <512CBE70.5000806@oracle.com> <6778CFAD-CAD1-4F67-9F37-1272C2A60F58@oracle.com> <1193BF01-2E57-4E5C-882B-389E0F00A010@oracle.com> <1C7668AC-7892-4496-9ED1-A70C4072EFDC@oracle.com> <8AA0E10B-6B2E-47AF-AE61-1B0112CAEA10@oracle.com> Message-ID: <512D1BB4.6030700@oracle.com> David, On 2013-02-26 22:44, David DeHaven wrote: > > config.status does other things too, it's quite handy. Yes. The only problem with it - I typically forget to copy it out before doing rm -rf build -Dmitry > > -DrD- > >> Awsome! >> >> Thanks, >> /Staffan >> >> On 26 feb 2013, at 16:31, David DeHaven wrote: >> >>> >>> build//config.status --recheck >>> >>> -DrD- >>> >>>> Thanks Dmitry, >>>> >>>> I was looking for a standard way of doing this. While a custom script helps, it would be nice to have the support in the source. >>>> >>>> /Staffan >>>> >>>> On 26 feb 2013, at 14:53, Dmitry Samersoff wrote: >>>> >>>>> Staffan, >>>>> >>>>> 1. Keep config.log somewhere >>>>> 2. Attached script or something similar will do the trick >>>>> >>>>> -Dmitry >>>>> >>>>> On 2013-02-26 13:05, Staffan Larsen wrote: >>>>>> Is there a shorthand for re-running configure on one of my >>>>>> configurations without having to re-type the configure arguments I >>>>>> used when creating the configuration? >>>>>> >>>>>> I have a number of configurations and when I have to re-run >>>>>> configure, I have to both specify the correct --with-conf-name and >>>>>> then the correct configure options I used last time. I know I can >>>>>> find those in the configure-arguments file. >>>>>> >>>>>> What I would like is something simliar to "make CONF=..." but for >>>>>> configure: "sh configure CONF=...". >>>>>> >>>>>> Thanks, /Staffan >>>>>> >>>>> >>>>> >>>>> -- >>>>> Dmitry Samersoff >>>>> Oracle Java development team, Saint Petersburg, Russia >>>>> * Give Rabbit time, and he'll always get the answer >>>>> >>>> >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From david.katleman at oracle.com Tue Feb 26 21:48:30 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 26 Feb 2013 21:48:30 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b78 for changeset 27d6368ae8ba Message-ID: <20130226214831.E9BE947439@hg.openjdk.java.net> Changeset: e41fb1aa0329 Author: katleman Date: 2013-02-21 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/e41fb1aa0329 Added tag jdk8-b78 for changeset 27d6368ae8ba ! .hgtags From david.katleman at oracle.com Tue Feb 26 21:48:26 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 26 Feb 2013 21:48:26 +0000 Subject: hg: jdk8/build: 2 new changesets Message-ID: <20130226214826.D586347438@hg.openjdk.java.net> Changeset: 91d35211e744 Author: katleman Date: 2013-02-21 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/91d35211e744 Added tag jdk8-b78 for changeset fd1a5574cf68 ! .hgtags Changeset: 2778e6576e21 Author: katleman Date: 2013-02-26 13:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/2778e6576e21 Merge From david.katleman at oracle.com Tue Feb 26 21:54:23 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 26 Feb 2013 21:54:23 +0000 Subject: hg: jdk8/build/hotspot: Added tag jdk8-b78 for changeset d5e12e7d2f71 Message-ID: <20130226215427.769DB4743A@hg.openjdk.java.net> Changeset: db3359133cdd Author: katleman Date: 2013-02-21 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/db3359133cdd Added tag jdk8-b78 for changeset d5e12e7d2f71 ! .hgtags From david.katleman at oracle.com Tue Feb 26 21:56:39 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 26 Feb 2013 21:56:39 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b78 for changeset 391de4c992d1 Message-ID: <20130226215643.637AB4743C@hg.openjdk.java.net> Changeset: 70d8658d2a30 Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/70d8658d2a30 Added tag jdk8-b78 for changeset 391de4c992d1 ! .hgtags From david.katleman at oracle.com Tue Feb 26 21:56:53 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 26 Feb 2013 21:56:53 +0000 Subject: hg: jdk8/build/jdk: 2 new changesets Message-ID: <20130226215727.2A7BE4743D@hg.openjdk.java.net> Changeset: bb97c93e4fd7 Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bb97c93e4fd7 Added tag jdk8-b78 for changeset 00b7535d743f ! .hgtags Changeset: f0b5b57014b3 Author: katleman Date: 2013-02-26 13:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f0b5b57014b3 Merge From david.katleman at oracle.com Tue Feb 26 21:56:29 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 26 Feb 2013 21:56:29 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b78 for changeset 00958c5a7070 Message-ID: <20130226215634.1F3524743B@hg.openjdk.java.net> Changeset: 58fa065dd5d6 Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/58fa065dd5d6 Added tag jdk8-b78 for changeset 00958c5a7070 ! .hgtags From david.katleman at oracle.com Tue Feb 26 22:02:12 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 26 Feb 2013 22:02:12 +0000 Subject: hg: jdk8/build/langtools: Added tag jdk8-b78 for changeset af8417e590f4 Message-ID: <20130226220217.7C8EF4743E@hg.openjdk.java.net> Changeset: 56dfafbb9e1a Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/56dfafbb9e1a Added tag jdk8-b78 for changeset af8417e590f4 ! .hgtags From mike.duigou at oracle.com Tue Feb 26 22:30:03 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 26 Feb 2013 14:30:03 -0800 Subject: 8009029: SunEC provider classes ending up in rt.jar after Nashorn build changes In-Reply-To: <512D1345.5060004@oracle.com> References: <512D1345.5060004@oracle.com> Message-ID: <6F4241AC-1132-4130-AE0A-8304E0CEB5CE@oracle.com> +1. This corrects the test issues I was seeing. Mike On Feb 26 2013, at 11:55 , Alan Bateman wrote: > > I ran into another issue cause from Nashorn build changes, also secondary expansion related. The issue is that some classes are going into rt.jar that shouldn't be there, particularly the SunEC provider, some charset classes too. I would like to push the attached patch to jdk8/tl to fix these issue. > > -Alan > > > diff --git a/makefiles/CreateJars.gmk b/makefiles/CreateJars.gmk > --- a/makefiles/CreateJars.gmk > +++ b/makefiles/CreateJars.gmk > @@ -213,28 +213,28 @@ > org/relaxng/datatype \ > sun/awt/HKSCS.class \ > sun/awt/motif/X11GB2312.class \ > - sun/awt/motif/X11GB2312\$$$$Decoder.class \ > - sun/awt/motif/X11GB2312\$$$$Encoder.class \ > + sun/awt/motif/X11GB2312\$$Decoder.class \ > + sun/awt/motif/X11GB2312\$$Encoder.class \ > sun/awt/motif/X11GBK.class \ > - sun/awt/motif/X11GBK\$$$$Encoder.class \ > + sun/awt/motif/X11GBK\$$Encoder.class \ > sun/awt/motif/X11KSC5601.class \ > - sun/awt/motif/X11KSC5601\$$$$Decoder.class \ > - sun/awt/motif/X11KSC5601\$$$$Encoder.class \ > + sun/awt/motif/X11KSC5601\$$Decoder.class \ > + sun/awt/motif/X11KSC5601\$$Encoder.class \ > sun/jvmstat \ > sun/net/spi/nameservice/dns \ > sun/nio/cs/ext \ > sun/rmi/rmic \ > sun/security/ec/ECDHKeyAgreement.class \ > sun/security/ec/ECDSASignature.class \ > - sun/security/ec/ECDSASignature\$$$$Raw.class \ > - sun/security/ec/ECDSASignature\$$$$SHA1.class \ > - sun/security/ec/ECDSASignature\$$$$SHA224.class \ > - sun/security/ec/ECDSASignature\$$$$SHA256.class \ > - sun/security/ec/ECDSASignature\$$$$SHA384.class \ > - sun/security/ec/ECDSASignature\$$$$SHA512.class \ > + sun/security/ec/ECDSASignature\$$Raw.class \ > + sun/security/ec/ECDSASignature\$$SHA1.class \ > + sun/security/ec/ECDSASignature\$$SHA224.class \ > + sun/security/ec/ECDSASignature\$$SHA256.class \ > + sun/security/ec/ECDSASignature\$$SHA384.class \ > + sun/security/ec/ECDSASignature\$$SHA512.class \ > sun/security/ec/ECKeyFactory.class \ > sun/security/ec/ECKeyPairGenerator.class \ > - sun/security/ec/SunEC\$$$$1.class \ > + sun/security/ec/SunEC\$$1.class \ > sun/security/ec/SunEC.class \ > sun/security/ec/SunECEntries.class \ > sun/security/internal \ From david.holmes at oracle.com Wed Feb 27 01:41:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Feb 2013 11:41:23 +1000 Subject: New build system problems In-Reply-To: <512CBBFD.5050001@oracle.com> References: <5129CD25.2000003@oracle.com> <512CBBFD.5050001@oracle.com> Message-ID: <512D6443.7010605@oracle.com> On 26/02/2013 11:43 PM, Dmitry Samersoff wrote: > Martin, > > On 2013-02-26 02:10, Martin Buchholz wrote: >> I'm willing to let someone else on build-dev take over this change, or I >> can implement some clear policy. >> It seems reasonable to do: >> >> windows => cl >> solaris => cc gcc >> anything else => gcc cc >> >> With environment variables to allow experimental use of >> insane^Wunsupported compilers. >> >> Do we have consensus on that? > > Sounds good for me. Me too. But I think we need to wait to hear from build-infra folk (as I understand it Erik is away at present). David > -Dmitry > > >> >> Martin >> >> On Sun, Feb 24, 2013 at 12:19 AM, Dmitry Samersoff >> > wrote: >> >> >> 1. for windows compiler checklist become: cl cc gcc >> >> I'm not sure we need to check for cc on windows, also gcc build on >> windows is not supported. So It might be better to be more explicit: >> >> 256 COMPILER_CHECK_LIST="cc gcc" >> # Overriding COMPILER_CHECK_LIST to set OS specific preferences >> 257 if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then >> 258 # Do not probe for cc on MacOSX. >> 259 COMPILER_CHECK_LIST="gcc" >> 260 fi >> 261 if test "x$OPENJDK_TARGET_OS" = "xwindows"; then >> 262 COMPILER_CHECK_LIST="cl" >> 263 fi >> >> >> 2. Not all versions of test support == as equation. It's better to use >> single one. and I would prefer to have quotes around xmacosx and >> xwindows just for consistency. i.e. >> >> if test "x$OPENJDK_TARGET_OS" = "xwindows"; >> >> -Dmitry >> >> >> On 2013-02-24 00:05, Martin Buchholz wrote: >> > Hi Erik, Tim, Kelly >> > >> > Here's a proposed fix for you to review: >> > >> > >> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/COMPILER_CHECK_LIST/ >> > >> > Martin >> > >> > On Fri, Jan 25, 2013 at 3:51 PM, Martin Buchholz >> >wrote: >> > >> >> I was trying out the shiny new build system. >> >> >> >> Problem: configure is not executable - must run bash ./configure >> >> It's traditional for configure scripts to be executable. >> >> >> >> Problem: Your life is hell if you have a non-compiler "cl" >> command on your >> >> PATH, even on Linux. >> >> >> >> checking for cl... /usr/bin/cl >> >> configure: Resolving CC (as /usr/bin/cl) failed, using /usr/bin/cl >> >> directly. >> >> >> >> with subsequent failure to compile. >> >> >> >> Even if you specify the compiler explicitly, it doesn't help: >> >> >> >> CC=/usr/bin/gcc CXX=/usr/bin/g++ bash ./configure >> >> >> >> Of course, one can work around this by creating a "tools dir", but >> >> excising the unloved cl from the configure script is tempting and >> effective. >> >> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * Give Rabbit time, and he'll always get the answer >> >> > > From christian.thalinger at oracle.com Wed Feb 27 02:09:10 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 26 Feb 2013 18:09:10 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <512C632B.3070206@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> Message-ID: On Feb 25, 2013, at 11:24 PM, David Holmes wrote: > On 26/02/2013 4:42 AM, Christian Thalinger wrote: >> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>> >>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>> >>>> This would be the first of three fixes: >>>> >>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>> >>> This logic is not suitable: >>> >>> 541 # Testing the built JVM >>> 542 ifeq ($(JAVA_HOME),) >>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>> 544 else >>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>> 546 endif >>> >>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >> >> That's not entirely correct. test_gamma uses your JAVA_HOME setting: > > This is so confusing. Our makefiles are an abomination! I couldn't agree more. > > So this all started because the makefile has: > > JAVA_HOME=$(ABS_BOOTDIR) > > which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. > > So how did the boot JDK come back into this??? > >> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >> >> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >> JAVA_HOME must point to a 64-bit OpenJDK. >> >> And here comes this little snippet into play: >> >> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >> >> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. > > I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. -- Chris > > Thanks, > David > >> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >> >>> >>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >> >> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >> >>> >>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >> >> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >> >> -- Chris >> >>> >>> And this addition still makes no sense to me: >>> >>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>> >>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>> >>> David >>> >>> >>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>> >>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>> >>>> -- Chris >>>> >>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>> >>>>> >>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>> >>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>> >>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>> >>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>> >>>>>>> 8006965: test_gamma should run with import JDK >>>>>>> Reviewed-by: >>>>>>> >>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>> >>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>> running test_gamma. >>>>>>> >>>>>>> make/bsd/makefiles/buildtree.make >>>>>>> make/defs.make >>>>>>> make/linux/makefiles/buildtree.make >>>>>>> make/solaris/makefiles/buildtree.make >>>>>>> >>>>>> >>>>> >>>> >> From david.holmes at oracle.com Wed Feb 27 02:47:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Feb 2013 12:47:29 +1000 Subject: Dollar ($) expansion still needs attention Message-ID: <512D73C1.50504@oracle.com> So ... nashorn pushed this change: http://hg.openjdk.java.net/jdk8/tl/diff/5b0b6ef58dbf/common/makefiles/MakeBase.gmk which modified the way $ gets handled in a file name, and in doing so completely broke many of the pre-existing escape sequences used for dealing with nested classes (those with $ in their name). I'm not 100% convinced that this actually relates to secondary expansion but ... Alan found and fixed both: 8008977: profiles build broken by Nashorn build changes and 8009029: SunEC provider classes ending up in rt.jar after Nashorn build changes However we have now ended up in a situation where nobody knows how to write the name of a nested class, without knowing how that name will actually get processed. If you look in CreateJars.gmk you will find: RT_JAR_EXCLUDES += \ ... sun/awt/motif/X11GB2312.class \ sun/awt/motif/X11GB2312\$$Decoder.class \ sun/awt/motif/X11GB2312\$$Encoder.class \ sun/awt/motif/X11GBK.class \ sun/awt/motif/X11GBK\$$Encoder.class \ sun/awt/motif/X11KSC5601.class \ sun/awt/motif/X11KSC5601\$$Decoder.class \ sun/awt/motif/X11KSC5601\$$Encoder.class \ (which were modified to fix 8009029) and later: ifneq ($(OPENJDK_TARGET_OS), windows) CHARSETS_EXTRA_FILES:=sun/awt/motif/X11GBK.class \ sun/awt/motif/X11GB2312\$$$$Decoder.class \ sun/awt/motif/X11GB2312.class \ sun/awt/motif/X11KSC5601\$$$$Decoder.class \ sun/awt/motif/X11KSC5601\$$$$Encoder.class \ sun/awt/motif/X11GB2312\$$$$Encoder.class \ sun/awt/motif/X11GBK\$$$$Encoder.class \ sun/awt/motif/X11KSC5601.class endif So the same file names are listed once with \$$ and once with \$$$$, and they both have to be that way to work! This is untenable. There should only be one way to write the name of a nested class file inside the makefile. FYI in Profiles.gmk when expanding foo/*.class I already had to do a similar substitution as is now in ListPathsSafely: # Function to expand foo/*.class into the set of classes # NOTE: Classfiles with $ in their name are problematic as that is the # meta-character for both make and the shell! Hence the \$$$$ substitution. # But note that if you echo these values they will NOT display as expected. class_list = $(patsubst $(JDK_OUTPUTDIR)/classes/%,%,\ $(foreach i,$(1), $(subst $$,\$$$$, $(wildcard $(JDK_OUTPUTDIR)/classes/$i)))) So I'd like to understand why the nashorn change was made so that we can determine how to get back to only having one way to specify file names containing $ David ----- From Alan.Bateman at oracle.com Wed Feb 27 10:15:56 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Feb 2013 10:15:56 +0000 Subject: Dollar ($) expansion still needs attention In-Reply-To: <512D73C1.50504@oracle.com> References: <512D73C1.50504@oracle.com> Message-ID: <512DDCDC.7080400@oracle.com> On 27/02/2013 02:47, David Holmes wrote: > : > > So the same file names are listed once with \$$ and once with \$$$$, > and they both have to be that way to work! > > This is untenable. There should only be one way to write the name of a > nested class file inside the makefile. > > FYI in Profiles.gmk when expanding foo/*.class I already had to do a > similar substitution as is now in ListPathsSafely: > > # Function to expand foo/*.class into the set of classes > # NOTE: Classfiles with $ in their name are problematic as that is the > # meta-character for both make and the shell! Hence the \$$$$ > substitution. > # But note that if you echo these values they will NOT display as > expected. > class_list = $(patsubst $(JDK_OUTPUTDIR)/classes/%,%,\ > $(foreach i,$(1), $(subst $$,\$$$$, $(wildcard > $(JDK_OUTPUTDIR)/classes/$i)))) > > > So I'd like to understand why the nashorn change was made so that we > can determine how to get back to only having one way to specify file > names containing $ I completely agree, it's very difficult to maintain. Also the two patches yesterday were just to get the build working again (Erik is out this week so it wasn't possible to establish why MakeBase.gmk was changed, also I cannot find the review thread to know if it came up during the review). -Alan From Alan.Bateman at oracle.com Wed Feb 27 13:11:32 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Feb 2013 13:11:32 +0000 Subject: 8008950: jdk8/tl failing with SetupJavaCompilation BUILD_NASGEN contains missing directory -c on Windows Message-ID: <512E0604.7070400@oracle.com> This is another patch to get jdk8/tl building again after the Nashorn build changes. The changes for 8009021 [1] that were pushed to jdk8/tl/nashorn yesterday break the build on Windows. The problem is that NASGEN_SRC and ASM_SRC shouldn't have $(FIXPATH) in the value. Kudos to David Holmes for identifying the problem. I've removed the $(FIXPATH) and verified that jdk8/tl builds on all platforms again. I'd like to get this into jdk8/tl today. -Alan [1] http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a90094ae5be3 diff --git a/makefiles/BuildNashorn.gmk b/makefiles/BuildNashorn.gmk --- a/makefiles/BuildNashorn.gmk +++ b/makefiles/BuildNashorn.gmk @@ -57,8 +57,8 @@ COPY:=.properties .js,\ BIN:=$(NASHORN_OUTPUTDIR)/nashorn_classes)) -NASGEN_SRC := $(FIXPATH) $(NASHORN_TOPDIR)/buildtools/nasgen/src -ASM_SRC := $(FIXPATH) $(JDK_TOPDIR)/src/share/classes/jdk/internal/org/objectweb/asm +NASGEN_SRC := $(NASHORN_TOPDIR)/buildtools/nasgen/src +ASM_SRC := $(JDK_TOPDIR)/src/share/classes/jdk/internal/org/objectweb/asm # Build nasgen $(eval $(call SetupJavaCompilation,BUILD_NASGEN,\ From chris.hegarty at oracle.com Wed Feb 27 14:00:52 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 27 Feb 2013 14:00:52 +0000 Subject: 8008950: jdk8/tl failing with SetupJavaCompilation BUILD_NASGEN contains missing directory -c on Windows In-Reply-To: <512E0604.7070400@oracle.com> References: <512E0604.7070400@oracle.com> Message-ID: <512E1194.1000701@oracle.com> If I understand fixpath correctly, only needs to be run/wrap commands (to convert path arguments), rather then on actual paths, then this looks fine to me. Great to see tl being buildable again. -Chris. On 27/02/2013 13:11, Alan Bateman wrote: > > This is another patch to get jdk8/tl building again after the Nashorn > build changes. > > The changes for 8009021 [1] that were pushed to jdk8/tl/nashorn > yesterday break the build on Windows. The problem is that NASGEN_SRC and > ASM_SRC shouldn't have $(FIXPATH) in the value. Kudos to David Holmes > for identifying the problem. I've removed the $(FIXPATH) and verified > that jdk8/tl builds on all platforms again. I'd like to get this into > jdk8/tl today. > > -Alan > > [1] http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a90094ae5be3 > > > diff --git a/makefiles/BuildNashorn.gmk b/makefiles/BuildNashorn.gmk > --- a/makefiles/BuildNashorn.gmk > +++ b/makefiles/BuildNashorn.gmk > @@ -57,8 +57,8 @@ > COPY:=.properties .js,\ > BIN:=$(NASHORN_OUTPUTDIR)/nashorn_classes)) > > -NASGEN_SRC := $(FIXPATH) $(NASHORN_TOPDIR)/buildtools/nasgen/src > -ASM_SRC := $(FIXPATH) > $(JDK_TOPDIR)/src/share/classes/jdk/internal/org/objectweb/asm > +NASGEN_SRC := $(NASHORN_TOPDIR)/buildtools/nasgen/src > +ASM_SRC := $(JDK_TOPDIR)/src/share/classes/jdk/internal/org/objectweb/asm > > # Build nasgen > $(eval $(call SetupJavaCompilation,BUILD_NASGEN,\ From ioi.lam at oracle.com Wed Feb 27 18:31:50 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 27 Feb 2013 10:31:50 -0800 Subject: Dollar ($) expansion still needs attention In-Reply-To: <512D73C1.50504@oracle.com> References: <512D73C1.50504@oracle.com> Message-ID: <512E5116.3010202@oracle.com> While we are cleaning this up, would it make sense to replace the maddening \ and $ with something like this? sun/awt/motif/X11GB2312${DOLLAR}Decoder.class - Ioi On 02/26/2013 06:47 PM, David Holmes wrote: > So ... nashorn pushed this change: > > http://hg.openjdk.java.net/jdk8/tl/diff/5b0b6ef58dbf/common/makefiles/MakeBase.gmk > > > which modified the way $ gets handled in a file name, and in doing so > completely broke many of the pre-existing escape sequences used for > dealing with nested classes (those with $ in their name). I'm not 100% > convinced that this actually relates to secondary expansion but ... > > Alan found and fixed both: > > 8008977: profiles build broken by Nashorn build changes > > and > > 8009029: SunEC provider classes ending up in rt.jar after Nashorn > build changes > > However we have now ended up in a situation where nobody knows how to > write the name of a nested class, without knowing how that name will > actually get processed. If you look in CreateJars.gmk you will find: > > RT_JAR_EXCLUDES += \ > ... > sun/awt/motif/X11GB2312.class \ > sun/awt/motif/X11GB2312\$$Decoder.class \ > sun/awt/motif/X11GB2312\$$Encoder.class \ > sun/awt/motif/X11GBK.class \ > sun/awt/motif/X11GBK\$$Encoder.class \ > sun/awt/motif/X11KSC5601.class \ > sun/awt/motif/X11KSC5601\$$Decoder.class \ > sun/awt/motif/X11KSC5601\$$Encoder.class \ > > (which were modified to fix 8009029) and later: > > ifneq ($(OPENJDK_TARGET_OS), windows) > CHARSETS_EXTRA_FILES:=sun/awt/motif/X11GBK.class \ > sun/awt/motif/X11GB2312\$$$$Decoder.class \ > sun/awt/motif/X11GB2312.class \ > sun/awt/motif/X11KSC5601\$$$$Decoder.class \ > sun/awt/motif/X11KSC5601\$$$$Encoder.class \ > sun/awt/motif/X11GB2312\$$$$Encoder.class \ > sun/awt/motif/X11GBK\$$$$Encoder.class \ > sun/awt/motif/X11KSC5601.class > endif > > So the same file names are listed once with \$$ and once with \$$$$, > and they both have to be that way to work! > > This is untenable. There should only be one way to write the name of a > nested class file inside the makefile. > > FYI in Profiles.gmk when expanding foo/*.class I already had to do a > similar substitution as is now in ListPathsSafely: > > # Function to expand foo/*.class into the set of classes > # NOTE: Classfiles with $ in their name are problematic as that is the > # meta-character for both make and the shell! Hence the \$$$$ > substitution. > # But note that if you echo these values they will NOT display as > expected. > class_list = $(patsubst $(JDK_OUTPUTDIR)/classes/%,%,\ > $(foreach i,$(1), $(subst $$,\$$$$, $(wildcard > $(JDK_OUTPUTDIR)/classes/$i)))) > > > So I'd like to understand why the nashorn change was made so that we > can determine how to get back to only having one way to specify file > names containing $ > > David > ----- > > From Mike.Duigou at oracle.COM Wed Feb 27 19:44:25 2013 From: Mike.Duigou at oracle.COM (Mike Duigou) Date: Wed, 27 Feb 2013 11:44:25 -0800 Subject: demos and images Message-ID: <38233775-E222-41E4-A306-5BCACDA0B7BA@oracle.COM> The demos target is being built as a pre-requisite to building images. This was probably done for compatibility the the old build system. How soon before we can we break this bogusness? Mike From martinrb at google.com Wed Feb 27 23:16:43 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 27 Feb 2013 15:16:43 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: <5128AD43.2000809@oracle.com> <51292295.4040802@oracle.com> Message-ID: I have another iteration of this change http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ that adds exciting new exception detail message for the InternalError I was scratching my head about earlier. - msg = strm->msg; + msg = ((strm->msg != NULL) ? strm->msg : + (ret == Z_VERSION_ERROR) ? + "zlib returned Z_VERSION_ERROR: " + "compile time and runtime zlib implementations differ" : + (ret == Z_STREAM_ERROR) ? + "inflateInit2 returned Z_STREAM_ERROR" : + "unknown error initializing zlib library"); From david.holmes at oracle.com Wed Feb 27 23:43:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Feb 2013 09:43:32 +1000 Subject: Dollar ($) expansion still needs attention In-Reply-To: <512E5116.3010202@oracle.com> References: <512D73C1.50504@oracle.com> <512E5116.3010202@oracle.com> Message-ID: <512E9A24.1020701@oracle.com> On 28/02/2013 4:31 AM, Ioi Lam wrote: > While we are cleaning this up, would it make sense to replace the > maddening \ and $ with something like this? > > sun/awt/motif/X11GB2312${DOLLAR}Decoder.class Perhaps. Though there would not be anything to tell people that this variable exists and that they should use it. I suspect that what we see now is that a variable that is subject to secondary expansion requires the \$$$$, while a variable not subject to secondary expansion requires \$$. Though I'm unsure how anything recently changed would have affected this aspect. David > - Ioi > > > On 02/26/2013 06:47 PM, David Holmes wrote: >> So ... nashorn pushed this change: >> >> http://hg.openjdk.java.net/jdk8/tl/diff/5b0b6ef58dbf/common/makefiles/MakeBase.gmk >> >> >> which modified the way $ gets handled in a file name, and in doing so >> completely broke many of the pre-existing escape sequences used for >> dealing with nested classes (those with $ in their name). I'm not 100% >> convinced that this actually relates to secondary expansion but ... >> >> Alan found and fixed both: >> >> 8008977: profiles build broken by Nashorn build changes >> >> and >> >> 8009029: SunEC provider classes ending up in rt.jar after Nashorn >> build changes >> >> However we have now ended up in a situation where nobody knows how to >> write the name of a nested class, without knowing how that name will >> actually get processed. If you look in CreateJars.gmk you will find: >> >> RT_JAR_EXCLUDES += \ >> ... >> sun/awt/motif/X11GB2312.class \ >> sun/awt/motif/X11GB2312\$$Decoder.class \ >> sun/awt/motif/X11GB2312\$$Encoder.class \ >> sun/awt/motif/X11GBK.class \ >> sun/awt/motif/X11GBK\$$Encoder.class \ >> sun/awt/motif/X11KSC5601.class \ >> sun/awt/motif/X11KSC5601\$$Decoder.class \ >> sun/awt/motif/X11KSC5601\$$Encoder.class \ >> >> (which were modified to fix 8009029) and later: >> >> ifneq ($(OPENJDK_TARGET_OS), windows) >> CHARSETS_EXTRA_FILES:=sun/awt/motif/X11GBK.class \ >> sun/awt/motif/X11GB2312\$$$$Decoder.class \ >> sun/awt/motif/X11GB2312.class \ >> sun/awt/motif/X11KSC5601\$$$$Decoder.class \ >> sun/awt/motif/X11KSC5601\$$$$Encoder.class \ >> sun/awt/motif/X11GB2312\$$$$Encoder.class \ >> sun/awt/motif/X11GBK\$$$$Encoder.class \ >> sun/awt/motif/X11KSC5601.class >> endif >> >> So the same file names are listed once with \$$ and once with \$$$$, >> and they both have to be that way to work! >> >> This is untenable. There should only be one way to write the name of a >> nested class file inside the makefile. >> >> FYI in Profiles.gmk when expanding foo/*.class I already had to do a >> similar substitution as is now in ListPathsSafely: >> >> # Function to expand foo/*.class into the set of classes >> # NOTE: Classfiles with $ in their name are problematic as that is the >> # meta-character for both make and the shell! Hence the \$$$$ >> substitution. >> # But note that if you echo these values they will NOT display as >> expected. >> class_list = $(patsubst $(JDK_OUTPUTDIR)/classes/%,%,\ >> $(foreach i,$(1), $(subst $$,\$$$$, $(wildcard >> $(JDK_OUTPUTDIR)/classes/$i)))) >> >> >> So I'd like to understand why the nashorn change was made so that we >> can determine how to get back to only having one way to specify file >> names containing $ >> >> David >> ----- >> >> > From Alan.Bateman at oracle.com Thu Feb 28 14:03:23 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Feb 2013 14:03:23 +0000 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: <5128AD43.2000809@oracle.com> <51292295.4040802@oracle.com> Message-ID: <512F63AB.2050204@oracle.com> On 27/02/2013 23:16, Martin Buchholz wrote: > I have another iteration of this change > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ > > that adds exciting new exception detail message for the InternalError > I was scratching my head about earlier. > > - msg = strm->msg; > + msg = ((strm->msg != NULL) ? strm->msg : > + (ret == Z_VERSION_ERROR) ? > + "zlib returned Z_VERSION_ERROR: " > + "compile time and runtime zlib implementations differ" : > + (ret == Z_STREAM_ERROR) ? > + "inflateInit2 returned Z_STREAM_ERROR" : > + "unknown error initializing zlib library"); The update to make/java/zip/Makefile looks good to me, we should have done it a long time ago. I assume you are pushing ahead on this because you want to push it to jdk7u-dev (as it's not interesting to jdk8 now because of the new build). The exciting new exception detail change looks okay to me too although it is hard to read. It wasn't immediately obvious to me why stddef.h was needed and we'd need to make sure that is okay on all platforms. -Alan. From martinrb at google.com Thu Feb 28 16:11:45 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 28 Feb 2013 08:11:45 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: <512F63AB.2050204@oracle.com> References: <5128AD43.2000809@oracle.com> <51292295.4040802@oracle.com> <512F63AB.2050204@oracle.com> Message-ID: On Thu, Feb 28, 2013 at 6:03 AM, Alan Bateman wrote: > The update to make/java/zip/Makefile looks good to me, we should have > done it a long time ago. I assume you are pushing ahead on this because you > want to push it to jdk7u-dev (as it's not interesting to jdk8 now because > of the new build). > Yes I'm hoping you push this fix to jdk7u. Also, I'm not sure that the new build system will not try to be bug-for-bug compatible with the old one and will reintroduce the problem. > The exciting new exception detail change looks okay to me too although it > is hard to read. It wasn't immediately obvious to me why stddef.h was > needed and we'd need to make sure that is okay on all platforms. > It's hard to find something more standard than stddef.h. "Include What You Use" ==> "always #include in any source file that uses NULL." From kelly.ohair at oracle.com Thu Feb 28 18:44:00 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 28 Feb 2013 10:44:00 -0800 Subject: Dollar ($) expansion still needs attention In-Reply-To: <512E9A24.1020701@oracle.com> References: <512D73C1.50504@oracle.com> <512E5116.3010202@oracle.com> <512E9A24.1020701@oracle.com> Message-ID: Just FYI... The x+=y is a unique make variable assignment, I think it evaluates the right or the entire variable or something. --- Also, as I recall, very vaguely, at one point in time, some of these Def*.gmk files would get included multiple times in one make process. This caused issues and in some cases I had to add in the equivalent of the C header file protection from multiple inclusions, e.g. ifndef DEF_FOOBAR DEF_FOOBAR=true < All of Defs_foobar.gmk > endif The nested Defs*.gmk inclusions are a nightmare. So be careful. -kto On Feb 27, 2013, at 3:43 PM, David Holmes wrote: > On 28/02/2013 4:31 AM, Ioi Lam wrote: >> While we are cleaning this up, would it make sense to replace the >> maddening \ and $ with something like this? >> >> sun/awt/motif/X11GB2312${DOLLAR}Decoder.class > > Perhaps. Though there would not be anything to tell people that this variable exists and that they should use it. > > I suspect that what we see now is that a variable that is subject to secondary expansion requires the \$$$$, while a variable not subject to secondary expansion requires \$$. Though I'm unsure how anything recently changed would have affected this aspect. > > David > >> - Ioi >> >> >> On 02/26/2013 06:47 PM, David Holmes wrote: >>> So ... nashorn pushed this change: >>> >>> http://hg.openjdk.java.net/jdk8/tl/diff/5b0b6ef58dbf/common/makefiles/MakeBase.gmk >>> >>> >>> which modified the way $ gets handled in a file name, and in doing so >>> completely broke many of the pre-existing escape sequences used for >>> dealing with nested classes (those with $ in their name). I'm not 100% >>> convinced that this actually relates to secondary expansion but ... >>> >>> Alan found and fixed both: >>> >>> 8008977: profiles build broken by Nashorn build changes >>> >>> and >>> >>> 8009029: SunEC provider classes ending up in rt.jar after Nashorn >>> build changes >>> >>> However we have now ended up in a situation where nobody knows how to >>> write the name of a nested class, without knowing how that name will >>> actually get processed. If you look in CreateJars.gmk you will find: >>> >>> RT_JAR_EXCLUDES += \ >>> ... >>> sun/awt/motif/X11GB2312.class \ >>> sun/awt/motif/X11GB2312\$$Decoder.class \ >>> sun/awt/motif/X11GB2312\$$Encoder.class \ >>> sun/awt/motif/X11GBK.class \ >>> sun/awt/motif/X11GBK\$$Encoder.class \ >>> sun/awt/motif/X11KSC5601.class \ >>> sun/awt/motif/X11KSC5601\$$Decoder.class \ >>> sun/awt/motif/X11KSC5601\$$Encoder.class \ >>> >>> (which were modified to fix 8009029) and later: >>> >>> ifneq ($(OPENJDK_TARGET_OS), windows) >>> CHARSETS_EXTRA_FILES:=sun/awt/motif/X11GBK.class \ >>> sun/awt/motif/X11GB2312\$$$$Decoder.class \ >>> sun/awt/motif/X11GB2312.class \ >>> sun/awt/motif/X11KSC5601\$$$$Decoder.class \ >>> sun/awt/motif/X11KSC5601\$$$$Encoder.class \ >>> sun/awt/motif/X11GB2312\$$$$Encoder.class \ >>> sun/awt/motif/X11GBK\$$$$Encoder.class \ >>> sun/awt/motif/X11KSC5601.class >>> endif >>> >>> So the same file names are listed once with \$$ and once with \$$$$, >>> and they both have to be that way to work! >>> >>> This is untenable. There should only be one way to write the name of a >>> nested class file inside the makefile. >>> >>> FYI in Profiles.gmk when expanding foo/*.class I already had to do a >>> similar substitution as is now in ListPathsSafely: >>> >>> # Function to expand foo/*.class into the set of classes >>> # NOTE: Classfiles with $ in their name are problematic as that is the >>> # meta-character for both make and the shell! Hence the \$$$$ >>> substitution. >>> # But note that if you echo these values they will NOT display as >>> expected. >>> class_list = $(patsubst $(JDK_OUTPUTDIR)/classes/%,%,\ >>> $(foreach i,$(1), $(subst $$,\$$$$, $(wildcard >>> $(JDK_OUTPUTDIR)/classes/$i)))) >>> >>> >>> So I'd like to understand why the nashorn change was made so that we >>> can determine how to get back to only having one way to specify file >>> names containing $ >>> >>> David >>> ----- >>> >>> >> From david.katleman at oracle.com Thu Feb 28 19:42:17 2013 From: david.katleman at oracle.com (David Katleman) Date: Thu, 28 Feb 2013 11:42:17 -0800 Subject: Review Request: JDK-8009196 install doesn't define $(AR) as /usr/ccs/bin/ar, results in ar: Command not found Message-ID: <512FB319.9000506@oracle.com> Modification to an earlier fix which broke internal Solaris builds, because ar could not be found. Rather than the hatchet Erik's fix took to the problem, separating the CROSS_COMPILE_ARCH portion into it's own if, and the second portion into it's own Solaris only if since the ccs path is valid only on Solaris, and the original fix was to avoid this whole section for Windows. http://cr.openjdk.java.net/~katleman/8009196/webrev.jdk.01/ For reference, the original fix http://cr.openjdk.java.net/~erikj/8007903/webrev.jdk.01/ Thanks Dave From tim.bell at oracle.com Thu Feb 28 20:25:17 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 28 Feb 2013 12:25:17 -0800 Subject: Review Request: JDK-8009196 install doesn't define $(AR) as /usr/ccs/bin/ar, results in ar: Command not found In-Reply-To: <512FB319.9000506@oracle.com> References: <512FB319.9000506@oracle.com> Message-ID: <512FBD2D.9080809@oracle.com> Hi Dave Don't you need to address the other file as well (make/common/shared/Compiler-msvc.gmk) by moving the endif from 91 up to line 40? Seems like the version checks will not be filled in and the Windows build should fail the sanity check. Do the release builds run sanity checks? Tim On 02/28/13 11:42, David Katleman wrote: > Modification to an earlier fix which broke internal Solaris builds, > because ar could not be found. > > Rather than the hatchet Erik's fix took to the problem, separating the > CROSS_COMPILE_ARCH portion into it's own if, and the second portion > into it's own Solaris only if since the ccs path is valid only on > Solaris, and the original fix was to avoid this whole section for > Windows. > > http://cr.openjdk.java.net/~katleman/8009196/webrev.jdk.01/ > > For reference, the original fix > > http://cr.openjdk.java.net/~erikj/8007903/webrev.jdk.01/ > > Thanks > Dave From david.katleman at oracle.com Thu Feb 28 20:39:04 2013 From: david.katleman at oracle.com (David Katleman) Date: Thu, 28 Feb 2013 12:39:04 -0800 Subject: Review Request: JDK-8009196 install doesn't define $(AR) as /usr/ccs/bin/ar, results in ar: Command not found In-Reply-To: <512FBD2D.9080809@oracle.com> References: <512FB319.9000506@oracle.com> <512FBD2D.9080809@oracle.com> Message-ID: <512FC068.9030107@oracle.com> On 2/28/2013 12:25 PM, Tim Bell wrote: > Hi Dave > > Don't you need to address the other file as well > (make/common/shared/Compiler-msvc.gmk) by moving the endif from 91 up > to line 40? Since the original fix was to address windows build issues, and windows builds fine, I left Compiler-msvc.gmk alone, the entire section is windows only. In Defs-utils.gmk, that whole section was buggy, since if CROSS_COMPILE_ARCH wasn't defined, we automatically set those 5 definitions to something very Solaris specific? Using CONFIGURE_BUILD was a windows bandaid that happened to build everywhere (but only if /usr/ccs/bin was in your path for Solaris) > Seems like the version checks will not be filled in and the Windows > build should fail the sanity check. Do the release builds run sanity > checks? Yes, we run the sanity checks (kitchen sink) Dave > On 02/28/13 11:42, David Katleman wrote: >> Modification to an earlier fix which broke internal Solaris builds, >> because ar could not be found. >> >> Rather than the hatchet Erik's fix took to the problem, separating >> the CROSS_COMPILE_ARCH portion into it's own if, and the second >> portion into it's own Solaris only if since the ccs path is valid >> only on Solaris, and the original fix was to avoid this whole section >> for Windows. >> >> http://cr.openjdk.java.net/~katleman/8009196/webrev.jdk.01/ >> >> For reference, the original fix >> >> http://cr.openjdk.java.net/~erikj/8007903/webrev.jdk.01/ >> >> Thanks >> Dave > > From tim.bell at oracle.com Thu Feb 28 20:44:59 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 28 Feb 2013 12:44:59 -0800 Subject: Review Request: JDK-8009196 install doesn't define $(AR) as /usr/ccs/bin/ar, results in ar: Command not found In-Reply-To: <512FC068.9030107@oracle.com> References: <512FB319.9000506@oracle.com> <512FBD2D.9080809@oracle.com> <512FC068.9030107@oracle.com> Message-ID: <512FC1CB.4080307@oracle.com> OK, thumbs up. Approved. Tim On 02/28/13 12:39, David Katleman wrote: > > On 2/28/2013 12:25 PM, Tim Bell wrote: >> Hi Dave >> >> Don't you need to address the other file as well >> (make/common/shared/Compiler-msvc.gmk) by moving the endif from 91 up >> to line 40? > > Since the original fix was to address windows build issues, and > windows builds fine, I left Compiler-msvc.gmk alone, the entire > section is windows only. > > In Defs-utils.gmk, that whole section was buggy, since if > CROSS_COMPILE_ARCH wasn't defined, we automatically set those 5 > definitions to something very Solaris specific? > > Using CONFIGURE_BUILD was a windows bandaid that happened to build > everywhere (but only if /usr/ccs/bin was in your path for Solaris) > >> Seems like the version checks will not be filled in and the Windows >> build should fail the sanity check. Do the release builds run sanity >> checks? > > Yes, we run the sanity checks (kitchen sink) > > Dave >> On 02/28/13 11:42, David Katleman wrote: >>> Modification to an earlier fix which broke internal Solaris builds, >>> because ar could not be found. >>> >>> Rather than the hatchet Erik's fix took to the problem, separating >>> the CROSS_COMPILE_ARCH portion into it's own if, and the second >>> portion into it's own Solaris only if since the ccs path is valid >>> only on Solaris, and the original fix was to avoid this whole >>> section for Windows. >>> >>> http://cr.openjdk.java.net/~katleman/8009196/webrev.jdk.01/ >>> >>> For reference, the original fix >>> >>> http://cr.openjdk.java.net/~erikj/8007903/webrev.jdk.01/ >>> >>> Thanks >>> Dave >> >> > From david.katleman at oracle.com Thu Feb 28 20:57:26 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 28 Feb 2013 20:57:26 +0000 Subject: hg: jdk8/build/hotspot: 38 new changesets Message-ID: <20130228205849.9116C474C4@hg.openjdk.java.net> Changeset: 57b81d6c3641 Author: amurillo Date: 2013-02-15 13:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/57b81d6c3641 8008286: new hotspot build - hs25-b20 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 7adae9244bc8 Author: mgronlun Date: 2013-02-13 11:23 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7adae9244bc8 8007312: null check signal semaphore in os::signal_notify windows Reviewed-by: dholmes, sla ! src/os/windows/vm/os_windows.cpp Changeset: 2394a89e89f4 Author: rbackman Date: 2013-02-13 09:46 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2394a89e89f4 8008088: SA can hang the VM Reviewed-by: mgronlun, sla, dholmes ! agent/src/os/bsd/libproc_impl.c ! agent/src/os/bsd/libproc_impl.h ! agent/src/os/bsd/ps_proc.c ! agent/src/os/linux/libproc_impl.c ! agent/src/os/linux/libproc_impl.h ! agent/src/os/linux/ps_proc.c Changeset: 49618582fc5b Author: sla Date: 2013-02-14 13:08 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/49618582fc5b 8004840: Jstack seems to output unnecessary information in 7u9 Reviewed-by: dholmes, coleenp, sspitsyn, rbackman ! agent/src/share/classes/sun/jvm/hotspot/memory/CMSCollector.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java Changeset: 3a531d40ad93 Author: acorn Date: 2013-02-14 14:33 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3a531d40ad93 8007736: VerifyError for static method in interface Reviewed-by: dholmes, acorn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/vm/classfile/verifier.cpp + test/runtime/8007736/TestStaticIF.java Changeset: e7e9e08147fc Author: mikael Date: 2013-02-14 12:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e7e9e08147fc 8007639: Workaround for ccache in vm.make is incorrect Summary: Fixed makefile logic to correctly special case JRE_RELEASE_VERSION and vm_version.o Reviewed-by: dholmes, erikj ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make Changeset: 5d5c577296fd Author: sla Date: 2013-02-15 08:54 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5d5c577296fd 8008102: SA on OS X does not stop the attached process Reviewed-by: dholmes, rbackman ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: f35f1fbab3e1 Author: sla Date: 2013-02-15 10:08 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f35f1fbab3e1 Merge Changeset: dc1de5e78a85 Author: dsamersoff Date: 2013-02-15 10:29 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/dc1de5e78a85 Merge Changeset: f82bcc429e8c Author: sla Date: 2013-02-18 10:43 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f82bcc429e8c 8007901: SA: Don't read flag values as constants Reviewed-by: dholmes, mikael ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/runtime/vmStructs.cpp Changeset: b5e3ec9c69fa Author: sla Date: 2013-02-18 12:49 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b5e3ec9c69fa 8007779: os::die() on solaris should generate core file Reviewed-by: dholmes, rbackman ! src/os/solaris/vm/os_solaris.cpp Changeset: 5cd2fac2ae70 Author: hseigel Date: 2013-02-19 08:51 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5cd2fac2ae70 6749267: Signal handler should save/restore errno Summary: Save errno before processing signal, then restore it. Reviewed-by: acorn, sspitsyn ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: 56c364daccc3 Author: emc Date: 2013-02-19 11:36 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/56c364daccc3 8007153: Ensure that MethodParameters API works properly with RedefineClasses Summary: Adds code to HotSpot to properly update MethodParameter attributes' constant pool indexes when redefineClasses is called Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 1048edb5434a Author: coleenp Date: 2013-02-19 13:33 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1048edb5434a Merge Changeset: 20fff74158eb Author: sspitsyn Date: 2013-02-20 08:51 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/20fff74158eb Merge Changeset: bbc7936779f9 Author: brutisso Date: 2013-02-14 09:11 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bbc7936779f9 8006398: Add regression tests for deprectated GCs Reviewed-by: ehelin, jwilhelm, jmasa ! test/TEST.ROOT + test/gc/startup_warnings/TestCMS.java + test/gc/startup_warnings/TestCMSIncrementalMode.java + test/gc/startup_warnings/TestCMSNoIncrementalMode.java + test/gc/startup_warnings/TestDefNewCMS.java + test/gc/startup_warnings/TestG1.java + test/gc/startup_warnings/TestIncGC.java + test/gc/startup_warnings/TestParNewCMS.java + test/gc/startup_warnings/TestParNewSerialOld.java + test/gc/startup_warnings/TestParallelGC.java + test/gc/startup_warnings/TestParallelScavengeSerialOld.java + test/gc/startup_warnings/TestSerialGC.java Changeset: fd7b3770c77e Author: tamao Date: 2013-02-14 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fd7b3770c77e 8007764: Wrong initialized value of max_gc_pause_sec for an instance of class AdaptiveSizePolicy Summary: This is a fix of an initialization mistake for class AdaptiveSizePolicy. Reviewed-by: jmasa Contributed-by: Tao Mao ! src/share/vm/memory/collectorPolicy.cpp Changeset: ccc57295818b Author: johnc Date: 2013-02-19 16:22 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ccc57295818b 8006628: NEED_TEST for JDK-8002870 Summary: Regression test for 8000311. Verifies that PLABStats works with zero parallel GC threads. Reviewed-by: jmasa, johnc Contributed-by: Filipp Zhinkin + test/gc/8000311/Test8000311.java Changeset: b9c5e46bf915 Author: johnc Date: 2013-02-20 12:52 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b9c5e46bf915 8008188: Add regression test for 8005875 Summary: Add regression test for crash seen in 8005875. Test is run with G1 and PGCT=0 and issues "jcmd Thread.print" against itself. Without the fix for 8005875 the test will crash. Reviewed-by: brutisso + test/gc/TestG1ZeroPGCTJcmdThreadPrint.java Changeset: 5741d3fc502d Author: brutisso Date: 2013-02-21 13:13 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5741d3fc502d Merge Changeset: c59b7900a2bd Author: roland Date: 2013-02-18 09:06 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c59b7900a2bd 8007959: Use expensive node logic for more math nodes Summary: use expensive node logic for other more math nodes. Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/subnode.hpp Changeset: 514efad5e81a Author: drchase Date: 2013-02-18 14:29 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/514efad5e81a 8008180: Several tests in compiler/5091921 need more time to run Summary: Added an explicit timeouts. Reviewed-by: kvn, twisti ! test/compiler/5091921/Test6850611.java ! test/compiler/5091921/Test6890943.java ! test/compiler/5091921/Test6905845.java ! test/compiler/5091921/Test6992759.java Changeset: a2bc322ca273 Author: drchase Date: 2013-02-18 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a2bc322ca273 7102300: performance warnings cause results diff failure in Test6890943 Summary: Strip lines matching the performance warning from the output before diff. Reviewed-by: kvn ! test/compiler/5091921/Test6890943.sh Changeset: ad736b4683b4 Author: kvn Date: 2013-02-18 16:47 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ad736b4683b4 8004867: VM crashing with assert "share/vm/opto/node.hpp:357 - assert(i < _max) failed: oob" Summary: Added few checks and early bailout from Superword optimization to avoid such cases in a future. Reviewed-by: roland, twisti ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp + test/compiler/8004867/TestIntAtomicCAS.java + test/compiler/8004867/TestIntAtomicOrdered.java + test/compiler/8004867/TestIntAtomicVolatile.java + test/compiler/8004867/TestIntUnsafeCAS.java + test/compiler/8004867/TestIntUnsafeOrdered.java + test/compiler/8004867/TestIntUnsafeVolatile.java Changeset: 2e4b16122164 Author: vlivanov Date: 2013-02-21 06:29 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2e4b16122164 Merge Changeset: 579f6adb7f51 Author: jprovino Date: 2013-02-05 13:32 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/579f6adb7f51 8003539: Minimal VM don't react to -Dcom.sun.management and -XX:+ManagementServer Summary: A warning message should be displayed if these options are used with the Minimal VM. Reviewed-by: dholmes, dsamersoff ! src/share/vm/runtime/arguments.cpp Changeset: 9e2da96f9976 Author: bpittore Date: 2013-02-08 16:08 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9e2da96f9976 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 6c2da81297c5 Author: kvn Date: 2013-02-12 09:54 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6c2da81297c5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 84a926fe53d0 Author: bpittore Date: 2013-01-24 13:27 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/84a926fe53d0 8005722: Assert in c1_LIR.hpp incorrect wrt to number of register operands Summary: In LIR_OpVisitState::visit() the receiver operand is processed twice Reviewed-by: roland, vladidan ! src/share/vm/c1/c1_LIR.cpp Changeset: cf9a2071eeac Author: jprovino Date: 2013-02-14 11:07 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/cf9a2071eeac 8006878: Some non-existent GC source files are in the minimalVM exclude list. Summary: cmsPermGen.cpp, psPermGen.cpp have been removed. yieldWorkingGroup.cpp typo is fixed. immutableSpace.cpp was in the list twice. Reviewed-by: dholmes, jmasa ! make/excludeSrc.make ! src/share/vm/utilities/yieldingWorkgroup.cpp Changeset: 1605eef8e11e Author: jprovino Date: 2013-02-14 11:08 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1605eef8e11e 8003581: UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS Summary: Fix warning messages when selected garbage collectors are excluded from the minimal jvm. Reviewed-by: dholmes, cjplummer ! src/share/vm/runtime/arguments.cpp Changeset: 9c7d0948523f Author: jprovino Date: 2013-02-15 14:42 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9c7d0948523f Merge Changeset: 1ba18258caa4 Author: bpittore Date: 2013-02-15 21:53 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1ba18258caa4 Merge ! src/share/vm/runtime/arguments.cpp Changeset: abf488c22e09 Author: bpittore Date: 2013-02-20 23:29 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/abf488c22e09 Merge Changeset: 2af22eb04623 Author: vladidan Date: 2013-02-21 09:08 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2af22eb04623 Merge Changeset: ed96c6015470 Author: vladidan Date: 2013-02-21 11:39 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ed96c6015470 Merge Changeset: 555ec35a2507 Author: amurillo Date: 2013-02-22 10:02 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/555ec35a2507 Merge Changeset: 6691814929b6 Author: amurillo Date: 2013-02-22 10:02 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6691814929b6 Added tag hs25-b20 for changeset 555ec35a2507 ! .hgtags From david.katleman at oracle.com Thu Feb 28 21:00:32 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 28 Feb 2013 21:00:32 +0000 Subject: hg: jdk8/build/jdk: 3 new changesets Message-ID: <20130228210130.9BF3F474C5@hg.openjdk.java.net> Changeset: 5245b2f1c53d Author: ngthomas Date: 2013-02-21 17:55 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5245b2f1c53d 8008691: Build failure (NEWBUILD=false) on Mac Reviewed-by: art, anthony ! make/sun/lwawt/FILES_export_macosx.gmk Changeset: c933505d75c2 Author: dcherepanov Date: 2013-02-26 12:54 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c933505d75c2 Merge Changeset: 8d3dbb724859 Author: katleman Date: 2013-02-27 13:10 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8d3dbb724859 Merge From tao.mao at oracle.com Thu Feb 21 23:48:21 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 21 Feb 2013 15:48:21 -0800 Subject: Review Request: 8008451: Make mac builds on 10.8 work on 10.7 In-Reply-To: <20773.10674.494494.347984@oracle.com> References: <511D0FCD.4020803@oracle.com> <93A5D67B-22E9-4EB7-980E-3C8B3646DE6B@oracle.com> <511DF527.4080208@oracle.com> <511E0491.7070508@oracle.com> <5124E33C.3070903@oracle.com> <20773.10674.494494.347984@oracle.com> Message-ID: <5126B245.7040008@oracle.com> Please reply to this thread to make sure all interested parties can see it. Tao On 2/20/2013 11:53 AM, John Coomes wrote: > Erik Joelsson (erik.joelsson at oracle.com) wrote: >> I was wrong, just setting the macros below did not generate 10.7 >> compatible bits when built on 10.8. Since I already pushed the old >> solution (except for hotspot), I created a new bug. Here is a new set of >> patches, combining -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 and >> -mmacosx-version-min=10.7.0 and also setting the latter on the link >> command line. This combination both generates compatible binaries and >> treats newer API calls as errors, all verified. >> >> Sine the two parameters take their argument in different formats, the >> handling of defaults is a bit more complicated. The variable being sent >> around and that you can override on the command line is now >> MACOSX_VERSION_MIN=10.7.0, matching the parameter to the compiler/linker. >> >> It would be good if someone from hotspot could review the hotspot changes. >> >> http://cr.openjdk.java.net/~erikj/8008451/webrev.hotspot.01/ > The hotspot changes look good to me. > > -John > >> http://cr.openjdk.java.net/~erikj/8008451/webrev.root.01/ >> http://cr.openjdk.java.net/~erikj/8008451/webrev.jdk.01/ >> >> /Erik >> >> On 2013-02-15 10:49, Erik Joelsson wrote: >>> >>> On 2013-02-15 09:43, Erik Joelsson wrote: >>>> On 2013-02-14 18:04, David DeHaven wrote: >>>>>> Here are a series of patches that adds the following to all native >>>>>> compile lines on macosx: >>>>>> >>>>>> -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 >>>>>> -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 >>>>> I know I'm not a reviewer, but I have an opinion anyways :) >>>>> >>>>> Using "-mmacosx-version-min=10.7" seems more appropriate for the >>>>> latter, this is passed to the linker as well which I believe sets >>>>> version information in the Mach-O headers (in the form of a load >>>>> command) to prevent it from being loaded on older systems. The >>>>> MIN_REQUIRED macro is set to a value that matches what's passed to >>>>> the -mmacosx-version-min argument, so it doesn't need to be provided. >>>>> >>>>> >>>> The effect of the -mmacosx-version-min=10.7 when sent to the linker >>>> is to make any calls to newer APIs "softlinked". This means the >>>> library will still load fine on the older OS, but the application is >>>> responsible for only actually making the newer calls if they are >>>> available. This is a good feature if you knowingly want to support >>>> multiple versions of the OS and still use features in the newer OS >>>> when available. I do not believe we have the need for that and if we >>>> ever do, then these parameters will need to change. >>>> >>> It's true -mmacosx-version-min= also sets the macro >>> MAC_OS_X_VERSION_MIN_REQUIRED=, but I see no gain in changing just one >>> of them to something else just because it works. The format of the >>> parameter is also different (10.7 vs 1070) which would require us to >>> add logic for converting between the two. >>> >>> /Erik From james.laskey at oracle.com Wed Feb 27 12:14:15 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 27 Feb 2013 08:14:15 -0400 Subject: Dollar ($) expansion still needs attention In-Reply-To: <512DDCDC.7080400@oracle.com> References: <512D73C1.50504@oracle.com> <512DDCDC.7080400@oracle.com> Message-ID: <5763BF73-F88A-4CB3-843B-8398BAA52DB8@oracle.com> I wanted to double check and trace the origins of the MakeBase.gmk patch before I responded. It was part of the original set Erik sent me, but looking thru the other parts of the patch it's not clear why it was necessary. http://cr.openjdk.java.net/~erikj/nashorn-build/webrev.01/ -- Jim On 2013-02-27, at 6:15 AM, Alan Bateman wrote: > On 27/02/2013 02:47, David Holmes wrote: >> : >> >> So the same file names are listed once with \$$ and once with \$$$$, and they both have to be that way to work! >> >> This is untenable. There should only be one way to write the name of a nested class file inside the makefile. >> >> FYI in Profiles.gmk when expanding foo/*.class I already had to do a similar substitution as is now in ListPathsSafely: >> >> # Function to expand foo/*.class into the set of classes >> # NOTE: Classfiles with $ in their name are problematic as that is the >> # meta-character for both make and the shell! Hence the \$$$$ substitution. >> # But note that if you echo these values they will NOT display as expected. >> class_list = $(patsubst $(JDK_OUTPUTDIR)/classes/%,%,\ >> $(foreach i,$(1), $(subst $$,\$$$$, $(wildcard $(JDK_OUTPUTDIR)/classes/$i)))) >> >> >> So I'd like to understand why the nashorn change was made so that we can determine how to get back to only having one way to specify file names containing $ > I completely agree, it's very difficult to maintain. Also the two patches yesterday were just to get the build working again (Erik is out this week so it wasn't possible to establish why MakeBase.gmk was changed, also I cannot find the review thread to know if it came up during the review). > > -Alan