From david.holmes at oracle.com Mon Dec 1 00:09:40 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 01 Dec 2014 10:09:40 +1000 Subject: [8u60] RFR: 8038189: Add cross-platform compact profiles support Message-ID: <547BB1C4.1000303@oracle.com> Main bug is 8038189 but that is a closed bug, the open backport issue is: https://bugs.openjdk.java.net/browse/JDK-8066200 Compact Profiles support was added in 8, but only for the Linux platform. I've now generalized this support to all the other platforms. This is an 8u only change, targetting 8u60, as soon as the jdk8u/dev starts accepting things for 8u60. The changes are not that extensive - mostly generalizing the lists and accounting for different platforms putting files into different places (jre/lib/ vs jre/lib vs jre/bin). It isn't necessary to produce detailed per-platform lists as files that don't exist simply don't get copied; but when files are obviously platform specific then I add them under suitable guards. The biggest complexity comes from the debuginfo files, and in particular unzipped debuginfo files. This accounts for the bulk of the changes in profiles-includes.txt, as we try to identify the set of debug files that might exist for each library (and OSX is the main complication due to the .dSYM directory because the existing rules only copy files not directories). Suggestions for reducing the duplicated patterns would be appreciated. Platform specific contents were determined in conjunction with examination of what Jigsaw is using in JDK 9 for the base module. I tested all the main platforms (Windows, Linux, Solaris and OSX) and with/without zipping of debuginfo files. Note that Windows builds will not work with unzipped debuginfo files due to 8025936, but I checked that multiple debug info files were expanded into the right set of targets. webrevs: http://cr.openjdk.java.net/~dholmes/8038189/webrev.top/ make/Main.gmk: - Remove the os-check that constrained profiles to linux http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk/ make/CreateJars.gmk: - Check for empty variables (Solaris doesn't like them) - Fix # # comments - Add explicit targets for the beanless classes with $ in them (the % substitution doesn't work on all platforms when $ is also present) make/Images.gmk - Don't filter out server VM from compact profiles make/Import.gmk - Add Info.plist to the exported files (for unzipped debuginfo files - this is a general fix not profiles specific so may warrant its own CR) make/Profiles.gmk - Remove linux-only comment make/Tools.gmk - Fix tool definitions to use $(PATH_SEP) and quote cp entries make/profile-includes.txt - Bulk of changes as described above make/profile-rtjar-includes.txt - Additional packages that exist on OSX only (but don't need to be conditionally added) - NOTE: if AIX or other platform add platform specific packages not already included by an enclosing package, then they will also need to be added Thanks, David From Alan.Bateman at oracle.com Mon Dec 1 09:18:29 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 01 Dec 2014 09:18:29 +0000 Subject: [8u60] RFR: 8038189: Add cross-platform compact profiles support In-Reply-To: <547BB1C4.1000303@oracle.com> References: <547BB1C4.1000303@oracle.com> Message-ID: <547C3265.2000506@oracle.com> On 01/12/2014 00:09, David Holmes wrote: > : > > Compact Profiles support was added in 8, but only for the Linux > platform. I've now generalized this support to all the other > platforms. This is an 8u only change, targetting 8u60, as soon as the > jdk8u/dev starts accepting things for 8u60. > Just to to David's comment, this change does not need to be pushed to JDK 9 because the way that images are created will be completely replaced once JEP 220 is targeted and pushed to JDK 9. When that happens then it the "profiles" target will work on all platforms there too. -Alan From erik.joelsson at oracle.com Mon Dec 1 09:19:18 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 01 Dec 2014 10:19:18 +0100 Subject: [8u60] RFR: 8038189: Add cross-platform compact profiles support In-Reply-To: <547BB1C4.1000303@oracle.com> References: <547BB1C4.1000303@oracle.com> Message-ID: <547C3296.8000000@oracle.com> Hello David, Most of it looks good, but profile-includes.txt could certainly benefit from some reduction in duplication. (Aside from the extension of the file itself, which I find a bit weird, but it's already there.) The two common structures that I can see are: 1. Expanding debuginfo files for macosx. 2. Assigning/expanding libraries to the correct variable. For macosx debuginfo expanding, I would define a macro to something like this: # Expand the contents of the .dSYM directories on macosx. # Param 1 - debug files list # Param 2 - libraries list define expand-debuginfo $(if $(and $(filter-out true, $(ZIP_DEBUGINFO_FILES)), $(filter macosx, $(OPENJDK_TARGET_OS))), \ $(foreach i, $1, $(addsuffix /Contents/Info.plist, $i)) \ $(foreach i, $2, $(addsuffix /Contents/Resources/DWARF/$i, $(filter $i.%, $1))), \ $1) endef And use it like this: PROFILE_1_DEBUG_FILES := $(call expand-debuginfo, $(PROFILE_1_DEBUG_FILES), $(PROFILE_1_LIBRARIES)) Filtering out jsig can be done on the parameters at the macro call. For the conditional addprefix of OPENJDK_TARGET_CPU_LEGACY_LIB, I would do something like: ifeq (, $(findstring $(OPENJDK_TARGET_OS), windows macosx)) LIB_SUBDIR := $(OPENJDK_TARGET_CPU_LEGACY_LIB)/ else LIB_SUBDIR := endif And then always assign PROFILE_*_JRE_LIB_FILES with $(addprefix $(LIB_SUBDIR), ...). The conditional on Windows for assigning to ...BIN_FILES or ...LIB_FILES I would leave in place since I don't think a macro solution would make it easier to understand. /Erik On 2014-12-01 01:09, David Holmes wrote: > Main bug is 8038189 but that is a closed bug, the open backport issue is: > > https://bugs.openjdk.java.net/browse/JDK-8066200 > > Compact Profiles support was added in 8, but only for the Linux > platform. I've now generalized this support to all the other > platforms. This is an 8u only change, targetting 8u60, as soon as the > jdk8u/dev starts accepting things for 8u60. > > The changes are not that extensive - mostly generalizing the lists and > accounting for different platforms putting files into different places > (jre/lib/ vs jre/lib vs jre/bin). It isn't necessary to produce > detailed per-platform lists as files that don't exist simply don't get > copied; but when files are obviously platform specific then I add them > under suitable guards. > > The biggest complexity comes from the debuginfo files, and in > particular unzipped debuginfo files. This accounts for the bulk of the > changes in profiles-includes.txt, as we try to identify the set of > debug files that might exist for each library (and OSX is the main > complication due to the .dSYM directory because the existing rules > only copy files not directories). Suggestions for reducing the > duplicated patterns would be appreciated. > > Platform specific contents were determined in conjunction with > examination of what Jigsaw is using in JDK 9 for the base module. > > I tested all the main platforms (Windows, Linux, Solaris and OSX) and > with/without zipping of debuginfo files. Note that Windows builds will > not work with unzipped debuginfo files due to 8025936, but I checked > that multiple debug info files were expanded into the right set of > targets. > > webrevs: > > http://cr.openjdk.java.net/~dholmes/8038189/webrev.top/ > > make/Main.gmk: > - Remove the os-check that constrained profiles to linux > > http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk/ > > make/CreateJars.gmk: > - Check for empty variables (Solaris doesn't like them) > - Fix # # comments > - Add explicit targets for the beanless classes with $ in them (the % > substitution doesn't work on all platforms when $ is also present) > > make/Images.gmk > - Don't filter out server VM from compact profiles > > make/Import.gmk > - Add Info.plist to the exported files (for unzipped debuginfo files > - this is a general fix not profiles specific so may warrant its own CR) > > make/Profiles.gmk > - Remove linux-only comment > > make/Tools.gmk > - Fix tool definitions to use $(PATH_SEP) and quote cp entries > > make/profile-includes.txt > - Bulk of changes as described above > > make/profile-rtjar-includes.txt > - Additional packages that exist on OSX only (but don't need to be > conditionally added) > - NOTE: if AIX or other platform add platform specific packages not > already included by an enclosing package, then they will also need to > be added > > Thanks, > David From erik.joelsson at oracle.com Mon Dec 1 13:27:10 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 01 Dec 2014 14:27:10 +0100 Subject: RFR: JDK-8065576: Enable pipefail in the shell used by make to better detect build errors In-Reply-To: <54766066.9060206@oracle.com> References: <5475EA0E.6040405@oracle.com> <54766066.9060206@oracle.com> Message-ID: <547C6CAE.40600@oracle.com> Hello, New webrev, which addresses Magnus' concern below, and various fixes in Hotspot for incompatibilities with errexit. Webrev: http://cr.openjdk.java.net/~erikj/8065576/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8065576 For the LOG=trace issue Magnus described below, it was enough to just replace $$(BASH) with $$(SHELL) and things worked as expected for me. In Hotspot there were several instances of run command X, followed by "if test $? = 0" (or something similar). I changed this to "if X; then" as errexit ignores commands that are part of if-statement tests. Since this is now touching Hotspot makefiles, it will need to go in through a Hotspot group forest. /Erik On 2014-11-27 00:21, Magnus Ihse Bursie wrote: > > On 2014-11-26 15:56, Erik Joelsson wrote: >> Hello, >> >> Please review this build reliability fix. In JDK-8065138, we would >> have caught the error much faster if the build had failed instead of >> silently generating bad output. To avoid this in the future, this >> patch activates pipefail and errexit in the shell, when available. >> This means that long command lines, consisting of multiple commands, >> chained together either by pipes or ';', will fail the build >> regardless of which of the sub commands that failed. Currently, all >> but the last command would be ignored. >> >> Since these features my not always be available in all versions of >> bash, I added a check to configure for each of them and only enable >> them if they are available. I also had to fix some instances where we >> have 'grep' and 'find' returning non zero without it being an error. >> >> Thanks to Martin who suggested this in the first place. > > Thank you for fixing this so quickly! > > The webrev looks good as such, but I think you have missed how this > interact with common/bin/shell-tracer.sh. Which, unfortunately, is > non-trivial. :-( > > First of all, I realize that the existing line in MakeBase: > WRAPPER_SHELL:=$$(BASH) $$(SRC_ROOT)/common/bin/shell-tracer.sh > $$(if $$(findstring yes,$$(IS_GNU_TIME)),$$(TIME),-) > $$(OUTPUT_ROOT)/build-trace-time.log $$(BASH) > is incorrect. (It's my bad...) The last $$(BASH) is supposed to be the > old value of $(SHELL), according to shell-tracer.sh. So, even before > your fix, it should have been $$(SHELL), not $$(BASH). > > However, even if you fix that, I'm not sure how this will work with a > $(SHELL) that has spaces in it. I think you can get it working it by > sending "$$(SHELL)" as last argument in WRAPPER_SHELL, and updating > shell-tracer.sh, so that the assignment to OLD_SHELL keeps the "" > around $3, but the calls to "$OLD_SHELL" (note, two places) removes > the "". But you'll have to verify that. > > /Magnus From martijnverburg at gmail.com Mon Dec 1 15:23:33 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 1 Dec 2014 15:23:33 +0000 Subject: Official and community supported build platforms for JDK 8 and 9 In-Reply-To: <80D05DC7-C7F3-4169-A49C-92DE0ED4668E@reini.net> References: <546F82E0.9070909@oracle.com> <80D05DC7-C7F3-4169-A49C-92DE0ED4668E@reini.net> Message-ID: Likewise - is it possible to get edit access? Cheers, Martijn On 21 November 2014 at 20:46, Patrick Reinhart wrote: > Hi Magnus, > > > A recurring theme in the build-dev list is confusion on which platforms > it is possible to build OpenJDK. Unfortunately, information about this has > not been easy to gather. It has also not been clear what kind of build > issues the Build Team will respond to and with what kind of urgency. > > > > To help address this, I?ve created a publicly available wiki page: > https://wiki.openjdk.java.net/display/Build/Supported+build+platforms > > Nice work, that belongs on my shortcut list from now on. > > > Support for building on different platforms come in two varieties: > official support and community support. > > > > Oracle defines a number of official build platforms, with carefully > specified versions of operating systems, compilers and other build tools. > If you report a failure to build on any of these platforms, the report will > be processed with high priority from the build team in Oracle. Under normal > circumstances, a build on any of these platforms will always succeed. > > > > In addition to the official build platforms, OpenJDK can normally be > built on many more platforms. For these platforms, there is no guarantee > that the build will succeed. The Oracle build team can help to solve some > problems encountered, but only on a best-effort basis. In addition to the > Oracle build team, the OpenJDK community at large is welcome to help with > making OpenJDK compile on these platforms. > > > > The official and community supported build platforms are listed on the > wiki page. Note that build support is different for different versions of > the JDK. We welcome updates from the community to the list of community > supported platforms. If you have succeeded (or not!) in building OpenJDK on > a platform that is substantially different from the ones already listed, > please document your experience in the list. > > I?m able to fluently build JDK 8u and JDK 9 on Fedora 21 x64 > > > The list of community supported platforms on the wiki is currently much > shorter than the number of platforms I expect OpenJDK to build on. Once > again, please help us by filling in the wiki! > > > > /Magnus > > I would like to help improve also documentations for the community? > > Patrick From tim.bell at oracle.com Mon Dec 1 15:38:46 2014 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 01 Dec 2014 07:38:46 -0800 Subject: RFR: JDK-8065576: Enable pipefail in the shell used by make to better detect build errors In-Reply-To: <547C6CAE.40600@oracle.com> References: <5475EA0E.6040405@oracle.com> <54766066.9060206@oracle.com> <547C6CAE.40600@oracle.com> Message-ID: <547C8B86.9090501@oracle.com> Erik: > New webrev, which addresses Magnus' concern below, and various fixes > in Hotspot for incompatibilities with errexit. > > Webrev: http://cr.openjdk.java.net/~erikj/8065576/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8065576 Looks good to me. /Tim > For the LOG=trace issue Magnus described below, it was enough to just > replace $$(BASH) with $$(SHELL) and things worked as expected for me. > > In Hotspot there were several instances of run command X, followed by > "if test $? = 0" (or something similar). I changed this to "if X; > then" as errexit ignores commands that are part of if-statement tests. > > Since this is now touching Hotspot makefiles, it will need to go in > through a Hotspot group forest. > > /Erik > > On 2014-11-27 00:21, Magnus Ihse Bursie wrote: >> >> On 2014-11-26 15:56, Erik Joelsson wrote: >>> Hello, >>> >>> Please review this build reliability fix. In JDK-8065138, we would >>> have caught the error much faster if the build had failed instead of >>> silently generating bad output. To avoid this in the future, this >>> patch activates pipefail and errexit in the shell, when available. >>> This means that long command lines, consisting of multiple commands, >>> chained together either by pipes or ';', will fail the build >>> regardless of which of the sub commands that failed. Currently, all >>> but the last command would be ignored. >>> >>> Since these features my not always be available in all versions of >>> bash, I added a check to configure for each of them and only enable >>> them if they are available. I also had to fix some instances where >>> we have 'grep' and 'find' returning non zero without it being an error. >>> >>> Thanks to Martin who suggested this in the first place. >> >> Thank you for fixing this so quickly! >> >> The webrev looks good as such, but I think you have missed how this >> interact with common/bin/shell-tracer.sh. Which, unfortunately, is >> non-trivial. :-( >> >> First of all, I realize that the existing line in MakeBase: >> WRAPPER_SHELL:=$$(BASH) $$(SRC_ROOT)/common/bin/shell-tracer.sh >> $$(if $$(findstring yes,$$(IS_GNU_TIME)),$$(TIME),-) >> $$(OUTPUT_ROOT)/build-trace-time.log $$(BASH) >> is incorrect. (It's my bad...) The last $$(BASH) is supposed to be >> the old value of $(SHELL), according to shell-tracer.sh. So, even >> before your fix, it should have been $$(SHELL), not $$(BASH). >> >> However, even if you fix that, I'm not sure how this will work with a >> $(SHELL) that has spaces in it. I think you can get it working it by >> sending "$$(SHELL)" as last argument in WRAPPER_SHELL, and updating >> shell-tracer.sh, so that the assignment to OLD_SHELL keeps the "" >> around $3, but the calls to "$OLD_SHELL" (note, two places) removes >> the "". But you'll have to verify that. >> >> /Magnus > From pointo1d at gmail.com Mon Dec 1 16:01:06 2014 From: pointo1d at gmail.com (Dave Pointon) Date: Mon, 1 Dec 2014 16:01:06 +0000 Subject: RFR: JDK-8065576: Enable pipefail in the shell used by make to better detect build errors In-Reply-To: <547C6CAE.40600@oracle.com> References: <5475EA0E.6040405@oracle.com> <54766066.9060206@oracle.com> <547C6CAE.40600@oracle.com> Message-ID: Hiya Erik , In every make recipe that I've ever written, I've yet to use the '... run command ; if test $/; then ...' structure since I always run the shell with '-e' option enabled and if the command returns a non-zero error status, then shell picks it up - which explains why the majority of make(1) recipes that I write utilise a case statement since the case "var in ... does not return a non-zero error status for the shell to pick up on i.e. the shell picks up on and fails the recipe if $VAR is unset in the command '... test "x$$VAR" ...', whereas the same does not hold for the command '... case "x$$VAR" ...' - the command result is left entirely for the recipe to deal with as it sees fit. Best rgds , -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe On 1 December 2014 at 13:27, Erik Joelsson wrote: > Hello, > > New webrev, which addresses Magnus' concern below, and various fixes in > Hotspot for incompatibilities with errexit. > > Webrev: http://cr.openjdk.java.net/~erikj/8065576/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8065576 > > For the LOG=trace issue Magnus described below, it was enough to just > replace $$(BASH) with $$(SHELL) and things worked as expected for me. > > In Hotspot there were several instances of run command X, followed by "if > test $? = 0" (or something similar). I changed this to "if X; then" as > errexit ignores commands that are part of if-statement tests. > > Since this is now touching Hotspot makefiles, it will need to go in > through a Hotspot group forest. > > /Erik > > ?? > From iris.clark at oracle.com Mon Dec 1 19:02:33 2014 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 1 Dec 2014 11:02:33 -0800 (PST) Subject: Official and community supported build platforms for JDK 8 and 9 In-Reply-To: References: <546F82E0.9070909@oracle.com> <80D05DC7-C7F3-4169-A49C-92DE0ED4668E@reini.net> Message-ID: Hi, Martijn. > Likewise - is it possible to get edit access? https://wiki.openjdk.java.net/display/Build/Supported+build+platforms That wikispace is owned by the Build Group, so all Members of that Group as listed in the Census [0] should be able to edit the page. Thanks, iris [0] http://openjdk.java.net/census#build -----Original Message----- From: Martijn Verburg [mailto:martijnverburg at gmail.com] Sent: Monday, December 01, 2014 7:24 AM To: Patrick Reinhart Cc: jdk8-dev; build-dev; jdk9-dev at openjdk.java.net Subject: Re: Official and community supported build platforms for JDK 8 and 9 Likewise - is it possible to get edit access? Cheers, Martijn From staffan.friberg at oracle.com Tue Dec 2 00:08:05 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Mon, 01 Dec 2014 16:08:05 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) Message-ID: <547D02E5.8070507@oracle.com> Hi, Hopefully this is the right list for this discussion. As part of adding Microbenchmarks to the OpenJDK source tree, I'm trying to understand how we best would add the benchmark sources to the existing OpenJDK tree structure. Since the microbenchmark suite will cover all parts of the JDK, covering HotSpot, JDK libraries and Nashorn, it would be preferred to add the microbenchmark directory as a new top level directory. Something similar to the following structure. Having "benchmark" as the top-level directory would allow us to later add different types of benchmarks without colliding with the microbenchmark suite. / benchmark/microbenchmark/... hotspot/... jdk/... nashorn/... With this as the premise I can see the following 3 options for how this could be added to the source code layout 1. Part of jdk-root repository * Only makes sense if we want to move in a direction with fewer trees (and eventually a single tree) 2. Part of another already existing tree * Not sure if this is possible without converting and moving the directory to a subdirectory of that tree 3. New tree in the forest/tree structure * Most logical option as it follows the current setup and structure Anyone have any comments and/or concerns on the suggested directory location and the tree structure in option 3. Would the build-dev team be the right group to later help setup a new tree if decided to be the right way to go? Regards, Staffan From david.holmes at oracle.com Tue Dec 2 04:24:41 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Dec 2014 14:24:41 +1000 Subject: [8u60] RFR: 8038189: Add cross-platform compact profiles support In-Reply-To: <547C3296.8000000@oracle.com> References: <547BB1C4.1000303@oracle.com> <547C3296.8000000@oracle.com> Message-ID: <547D3F09.5010308@oracle.com> Erik, Many thanks for the makefile macro wizardry! I will incorporate, test and return with an updated webreb. David On 1/12/2014 7:19 PM, Erik Joelsson wrote: > Hello David, > > Most of it looks good, but profile-includes.txt could certainly benefit > from some reduction in duplication. (Aside from the extension of the > file itself, which I find a bit weird, but it's already there.) The two > common structures that I can see are: > 1. Expanding debuginfo files for macosx. > 2. Assigning/expanding libraries to the correct variable. > > For macosx debuginfo expanding, I would define a macro to something like > this: > > # Expand the contents of the .dSYM directories on macosx. > # Param 1 - debug files list > # Param 2 - libraries list > define expand-debuginfo > $(if $(and $(filter-out true, $(ZIP_DEBUGINFO_FILES)), $(filter > macosx, $(OPENJDK_TARGET_OS))), \ > $(foreach i, $1, $(addsuffix /Contents/Info.plist, $i)) \ > $(foreach i, $2, $(addsuffix /Contents/Resources/DWARF/$i, > $(filter $i.%, $1))), \ > $1) > endef > > And use it like this: > > PROFILE_1_DEBUG_FILES := $(call expand-debuginfo, > $(PROFILE_1_DEBUG_FILES), $(PROFILE_1_LIBRARIES)) > > Filtering out jsig can be done on the parameters at the macro call. > > For the conditional addprefix of OPENJDK_TARGET_CPU_LEGACY_LIB, I would > do something like: > > ifeq (, $(findstring $(OPENJDK_TARGET_OS), windows macosx)) > LIB_SUBDIR := $(OPENJDK_TARGET_CPU_LEGACY_LIB)/ > else > LIB_SUBDIR := > endif > > And then always assign PROFILE_*_JRE_LIB_FILES with $(addprefix > $(LIB_SUBDIR), ...). The conditional on Windows for assigning to > ...BIN_FILES or ...LIB_FILES I would leave in place since I don't think > a macro solution would make it easier to understand. > > /Erik > > > On 2014-12-01 01:09, David Holmes wrote: >> Main bug is 8038189 but that is a closed bug, the open backport issue is: >> >> https://bugs.openjdk.java.net/browse/JDK-8066200 >> >> Compact Profiles support was added in 8, but only for the Linux >> platform. I've now generalized this support to all the other >> platforms. This is an 8u only change, targetting 8u60, as soon as the >> jdk8u/dev starts accepting things for 8u60. >> >> The changes are not that extensive - mostly generalizing the lists and >> accounting for different platforms putting files into different places >> (jre/lib/ vs jre/lib vs jre/bin). It isn't necessary to produce >> detailed per-platform lists as files that don't exist simply don't get >> copied; but when files are obviously platform specific then I add them >> under suitable guards. >> >> The biggest complexity comes from the debuginfo files, and in >> particular unzipped debuginfo files. This accounts for the bulk of the >> changes in profiles-includes.txt, as we try to identify the set of >> debug files that might exist for each library (and OSX is the main >> complication due to the .dSYM directory because the existing rules >> only copy files not directories). Suggestions for reducing the >> duplicated patterns would be appreciated. >> >> Platform specific contents were determined in conjunction with >> examination of what Jigsaw is using in JDK 9 for the base module. >> >> I tested all the main platforms (Windows, Linux, Solaris and OSX) and >> with/without zipping of debuginfo files. Note that Windows builds will >> not work with unzipped debuginfo files due to 8025936, but I checked >> that multiple debug info files were expanded into the right set of >> targets. >> >> webrevs: >> >> http://cr.openjdk.java.net/~dholmes/8038189/webrev.top/ >> >> make/Main.gmk: >> - Remove the os-check that constrained profiles to linux >> >> http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk/ >> >> make/CreateJars.gmk: >> - Check for empty variables (Solaris doesn't like them) >> - Fix # # comments >> - Add explicit targets for the beanless classes with $ in them (the % >> substitution doesn't work on all platforms when $ is also present) >> >> make/Images.gmk >> - Don't filter out server VM from compact profiles >> >> make/Import.gmk >> - Add Info.plist to the exported files (for unzipped debuginfo files >> - this is a general fix not profiles specific so may warrant its own CR) >> >> make/Profiles.gmk >> - Remove linux-only comment >> >> make/Tools.gmk >> - Fix tool definitions to use $(PATH_SEP) and quote cp entries >> >> make/profile-includes.txt >> - Bulk of changes as described above >> >> make/profile-rtjar-includes.txt >> - Additional packages that exist on OSX only (but don't need to be >> conditionally added) >> - NOTE: if AIX or other platform add platform specific packages not >> already included by an enclosing package, then they will also need to >> be added >> >> Thanks, >> David > From martijnverburg at gmail.com Tue Dec 2 13:43:36 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 2 Dec 2014 13:43:36 +0000 Subject: Official and community supported build platforms for JDK 8 and 9 In-Reply-To: References: <546F82E0.9070909@oracle.com> <80D05DC7-C7F3-4169-A49C-92DE0ED4668E@reini.net> Message-ID: That's a no for now then - in that case - do folks just want us firing any updates we are aware of to this mailing list? Cheers, Martijn On 1 December 2014 at 19:02, Iris Clark wrote: > Hi, Martijn. > > > Likewise - is it possible to get edit access? > > https://wiki.openjdk.java.net/display/Build/Supported+build+platforms > > That wikispace is owned by the Build Group, so all Members of that Group > as listed in the Census [0] should be able to edit the page. > > Thanks, > iris > > [0] http://openjdk.java.net/census#build > > -----Original Message----- > From: Martijn Verburg [mailto:martijnverburg at gmail.com] > Sent: Monday, December 01, 2014 7:24 AM > To: Patrick Reinhart > Cc: jdk8-dev; build-dev; jdk9-dev at openjdk.java.net > Subject: Re: Official and community supported build platforms for JDK 8 > and 9 > > Likewise - is it possible to get edit access? > > Cheers, > Martijn > > From roger.riggs at oracle.com Tue Dec 2 14:48:20 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 02 Dec 2014 09:48:20 -0500 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547D02E5.8070507@oracle.com> References: <547D02E5.8070507@oracle.com> Message-ID: <547DD133.1050706@oracle.com> Hi Staffan, An earlier issue was keeping tests in sync with the code under test, hence the use of test directories within each repository. I think a structure in which the benchmarks for some function and the function itself are in the same repository that is easier to understand and maintain. $.02, Roger On 12/1/2014 7:08 PM, Staffan Friberg wrote: > Hi, > > Hopefully this is the right list for this discussion. > > As part of adding Microbenchmarks to the OpenJDK source tree, I'm > trying to understand how we best would add the benchmark sources to > the existing OpenJDK tree structure. > > Since the microbenchmark suite will cover all parts of the JDK, > covering HotSpot, JDK libraries and Nashorn, it would be preferred to > add the microbenchmark directory as a new top level directory. > Something similar to the following structure. Having "benchmark" as > the top-level directory would allow us to later add different types of > benchmarks without colliding with the microbenchmark suite. > > / > benchmark/microbenchmark/... > hotspot/... > jdk/... > nashorn/... > > With this as the premise I can see the following 3 options for how > this could be added to the source code layout > > 1. Part of jdk-root repository > * Only makes sense if we want to move in a direction with fewer > trees (and eventually a single tree) > 2. Part of another already existing tree > * Not sure if this is possible without converting and moving the > directory to a subdirectory of that tree > 3. New tree in the forest/tree structure > * Most logical option as it follows the current setup and structure > > > Anyone have any comments and/or concerns on the suggested directory > location and the tree structure in option 3. > > Would the build-dev team be the right group to later help setup a new > tree if decided to be the right way to go? > > Regards, > Staffan > From magnus.ihse.bursie at oracle.com Tue Dec 2 15:42:25 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 02 Dec 2014 16:42:25 +0100 Subject: Official and community supported build platforms for JDK 8 and 9 In-Reply-To: References: <546F82E0.9070909@oracle.com> <80D05DC7-C7F3-4169-A49C-92DE0ED4668E@reini.net> Message-ID: <547DDDE1.5030609@oracle.com> On 2014-12-02 14:43, Martijn Verburg wrote: > That's a no for now then - in that case - do folks just want us firing any > updates we are aware of to this mailing list? Yes, please do. I am aware that I have a backlog of already mailed additions. I'll try to address them as soon as time permits. But a mail here is not wasted, even if I can't process it right away. I will also update the wiki page to state that mailing updates to this list is the suggested procedure. (I was not aware when creating the page that edit rights were limited to the build group.) /Magnus > > Cheers, > Martijn > > On 1 December 2014 at 19:02, Iris Clark wrote: > >> Hi, Martijn. >> >>> Likewise - is it possible to get edit access? >> https://wiki.openjdk.java.net/display/Build/Supported+build+platforms >> >> That wikispace is owned by the Build Group, so all Members of that Group >> as listed in the Census [0] should be able to edit the page. >> >> Thanks, >> iris >> >> [0] http://openjdk.java.net/census#build >> >> -----Original Message----- >> From: Martijn Verburg [mailto:martijnverburg at gmail.com] >> Sent: Monday, December 01, 2014 7:24 AM >> To: Patrick Reinhart >> Cc: jdk8-dev; build-dev; jdk9-dev at openjdk.java.net >> Subject: Re: Official and community supported build platforms for JDK 8 >> and 9 >> >> Likewise - is it possible to get edit access? >> >> Cheers, >> Martijn >> >> From mark.reinhold at oracle.com Tue Dec 2 16:51:13 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 02 Dec 2014 08:51:13 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547D02E5.8070507@oracle.com> References: <547D02E5.8070507@oracle.com> Message-ID: <20141202085113.472452@eggemoggin.niobe.net> 2014/12/1 4:08 -0800, staffan.friberg at oracle.com: > Hopefully this is the right list for this discussion. This change is going to affect many more people than just those interested in the build. Suggest you float this on jdk9-dev. - Mark From martijnverburg at gmail.com Tue Dec 2 17:49:55 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 2 Dec 2014 17:49:55 +0000 Subject: Official and community supported build platforms for JDK 8 and 9 In-Reply-To: <547DDDE1.5030609@oracle.com> References: <546F82E0.9070909@oracle.com> <80D05DC7-C7F3-4169-A49C-92DE0ED4668E@reini.net> <547DDDE1.5030609@oracle.com> Message-ID: Thanks Magnus, appreciate it! Cheers, Martijn On 2 December 2014 at 15:42, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2014-12-02 14:43, Martijn Verburg wrote: > >> That's a no for now then - in that case - do folks just want us firing any >> updates we are aware of to this mailing list? >> > Yes, please do. > > I am aware that I have a backlog of already mailed additions. I'll try to > address them as soon as time permits. But a mail here is not wasted, even > if I can't process it right away. > > I will also update the wiki page to state that mailing updates to this > list is the suggested procedure. (I was not aware when creating the page > that edit rights were limited to the build group.) > > /Magnus > > >> Cheers, >> Martijn >> >> On 1 December 2014 at 19:02, Iris Clark wrote: >> >> Hi, Martijn. >>> >>> Likewise - is it possible to get edit access? >>>> >>> https://wiki.openjdk.java.net/display/Build/Supported+build+platforms >>> >>> That wikispace is owned by the Build Group, so all Members of that Group >>> as listed in the Census [0] should be able to edit the page. >>> >>> Thanks, >>> iris >>> >>> [0] http://openjdk.java.net/census#build >>> >>> -----Original Message----- >>> From: Martijn Verburg [mailto:martijnverburg at gmail.com] >>> Sent: Monday, December 01, 2014 7:24 AM >>> To: Patrick Reinhart >>> Cc: jdk8-dev; build-dev; jdk9-dev at openjdk.java.net >>> Subject: Re: Official and community supported build platforms for JDK 8 >>> and 9 >>> >>> Likewise - is it possible to get edit access? >>> >>> Cheers, >>> Martijn >>> >>> >>> > From staffan.friberg at oracle.com Tue Dec 2 19:53:34 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 02 Dec 2014 11:53:34 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547DD133.1050706@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> Message-ID: <547E18BE.2070201@oracle.com> Hi, (Adding the jdk9-dev list to increase the visibility of the discussion) With the multiple sub-repository commit mechanism improved I believe this might be less of an issue. JPRT can push JDK and HS changes at together and the same functionality should be possible to use for this as well. I wonder if the test issue earlier was that it was a completely separate repository outside of the JDK forest, and less of an issue when being part of the same forest as the JDK source code. Perhaps someone from SQE can chime? Otherwise the main reason for having a separate sub-repository on the top level is making it easier to find what benchmarks are available and have a single place to add new once avoid any risk of name duplication. JMH is superb in filtering during execution during runtime so running just a single test or a group of tests is very straight forward and the recommended way, rather than having multiple benchmark JARs. It also makes the build process easier as the building can be done using a single Makefile and a single benchmark JAR (actually two, one for JDK 8 compatible tests and one for JDK 9) that can be picked up by automatic performance testing. Cheers, Staffan On 12/02/2014 06:48 AM, roger riggs wrote: > Hi Staffan, > > An earlier issue was keeping tests in sync with the code under test, > hence > the use of test directories within each repository. > I think a structure in which the benchmarks for some function and the > function > itself are in the same repository that is easier to understand and > maintain. > > $.02, Roger > > > On 12/1/2014 7:08 PM, Staffan Friberg wrote: >> Hi, >> >> Hopefully this is the right list for this discussion. >> >> As part of adding Microbenchmarks to the OpenJDK source tree, I'm >> trying to understand how we best would add the benchmark sources to >> the existing OpenJDK tree structure. >> >> Since the microbenchmark suite will cover all parts of the JDK, >> covering HotSpot, JDK libraries and Nashorn, it would be preferred to >> add the microbenchmark directory as a new top level directory. >> Something similar to the following structure. Having "benchmark" as >> the top-level directory would allow us to later add different types >> of benchmarks without colliding with the microbenchmark suite. >> >> / >> benchmark/microbenchmark/... >> hotspot/... >> jdk/... >> nashorn/... >> >> With this as the premise I can see the following 3 options for how >> this could be added to the source code layout >> >> 1. Part of jdk-root repository >> * Only makes sense if we want to move in a direction with fewer >> trees (and eventually a single tree) >> 2. Part of another already existing tree >> * Not sure if this is possible without converting and moving the >> directory to a subdirectory of that tree >> 3. New tree in the forest/tree structure >> * Most logical option as it follows the current setup and structure >> >> >> Anyone have any comments and/or concerns on the suggested directory >> location and the tree structure in option 3. >> >> Would the build-dev team be the right group to later help setup a new >> tree if decided to be the right way to go? >> >> Regards, >> Staffan >> > From chris.hegarty at oracle.com Tue Dec 2 21:23:37 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 2 Dec 2014 21:23:37 +0000 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547E18BE.2070201@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> Message-ID: <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> Staffan, Having all the benchmarks located in a single place makes sense to me, but this doesn?t necessarily mean that they need their own repository, in the forest. If I can build, run, and test ( usual development cycle ) without any dependency on these benchmarks, or their infrastructure, essential working with a partial forest ( without the ?benchmark? repository ), then I can see the possible value in having a separate repository ( so I can skip cloning and updating it ). But, I?m not sure if that is a reasonable justification for a new repository, as it is probably at odds with your goals, or maybe not? -Chris On 2 Dec 2014, at 19:53, Staffan Friberg wrote: > Hi, > > (Adding the jdk9-dev list to increase the visibility of the discussion) > > With the multiple sub-repository commit mechanism improved I believe this might be less of an issue. JPRT can push JDK and HS changes at together and the same functionality should be possible to use for this as well. I wonder if the test issue earlier was that it was a completely separate repository outside of the JDK forest, and less of an issue when being part of the same forest as the JDK source code. Perhaps someone from SQE can chime? > > Otherwise the main reason for having a separate sub-repository on the top level is making it easier to find what benchmarks are available and have a single place to add new once avoid any risk of name duplication. JMH is superb in filtering during execution during runtime so running just a single test or a group of tests is very straight forward and the recommended way, rather than having multiple benchmark JARs. It also makes the build process easier as the building can be done using a single Makefile and a single benchmark JAR (actually two, one for JDK 8 compatible tests and one for JDK 9) that can be picked up by automatic performance testing. > > Cheers, > Staffan > > On 12/02/2014 06:48 AM, roger riggs wrote: >> Hi Staffan, >> >> An earlier issue was keeping tests in sync with the code under test, hence >> the use of test directories within each repository. >> I think a structure in which the benchmarks for some function and the function >> itself are in the same repository that is easier to understand and maintain. >> >> $.02, Roger >> >> >> On 12/1/2014 7:08 PM, Staffan Friberg wrote: >>> Hi, >>> >>> Hopefully this is the right list for this discussion. >>> >>> As part of adding Microbenchmarks to the OpenJDK source tree, I'm trying to understand how we best would add the benchmark sources to the existing OpenJDK tree structure. >>> >>> Since the microbenchmark suite will cover all parts of the JDK, covering HotSpot, JDK libraries and Nashorn, it would be preferred to add the microbenchmark directory as a new top level directory. Something similar to the following structure. Having "benchmark" as the top-level directory would allow us to later add different types of benchmarks without colliding with the microbenchmark suite. >>> >>> / >>> benchmark/microbenchmark/... >>> hotspot/... >>> jdk/... >>> nashorn/... >>> >>> With this as the premise I can see the following 3 options for how this could be added to the source code layout >>> >>> 1. Part of jdk-root repository >>> * Only makes sense if we want to move in a direction with fewer >>> trees (and eventually a single tree) >>> 2. Part of another already existing tree >>> * Not sure if this is possible without converting and moving the >>> directory to a subdirectory of that tree >>> 3. New tree in the forest/tree structure >>> * Most logical option as it follows the current setup and structure >>> >>> >>> Anyone have any comments and/or concerns on the suggested directory location and the tree structure in option 3. >>> >>> Would the build-dev team be the right group to later help setup a new tree if decided to be the right way to go? >>> >>> Regards, >>> Staffan >>> >> > From jonathan.gibbons at oracle.com Tue Dec 2 21:59:56 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 02 Dec 2014 13:59:56 -0800 Subject: build warnings Message-ID: <547E365C.6040609@oracle.com> Build folk, The build has always generated warnings (sigh!) but right now, the warnings look scarier than usual. In particular, when the build terminates, I get a couple of screenfuls of messages like this: /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: In function ?SplashScreenThread?: /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9: warning: ignoring return value of ?pipe?, declared with attribute warn_unused_result [-Wunused-result] pipe(splash->controlpipe); ^ /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c: In function ?initFormat?: /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34: warning: ?numBits? may be used uninitialized in this function [-Wmaybe-uninitialized] format->shift[i] = shift + numBits - i * 8 - 8; ^ What would it take to have some sort of campaign to reduce build warnings like these? We've made good progress on lint and doclint warnings for Java code and doc comments; what does it take to start on native code warnings? -- Jon From staffan.friberg at oracle.com Tue Dec 2 22:08:20 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 02 Dec 2014 14:08:20 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> Message-ID: <547E3854.3060705@oracle.com> Hi Chris, Agree, there is no major reason this needs to be a new repository, as I mentioned in the 3 options below it would work well without it. The main thing I want to achieve is that the benchmarks are located on the top level. The suite will contain benchmarks for all parts of the JDK so having it in either jdk or hotspot doesn't feel like it makes sense. If people agree on having it as folder in the top level JDK repository I'm perfectly fine with that. As for building it will most likely not be of the general build process for building the JDK (do not want to increase the compilation time for anyone not requiring the benchmark suite). It would have its own target 'build-microbenchmark' which would depend on 'exploded-image', but not the reverse. //Staffan On 12/02/2014 01:23 PM, Chris Hegarty wrote: > Staffan, > > Having all the benchmarks located in a single place makes sense to me, but this doesn?t necessarily mean that they need their own repository, in the forest. > > If I can build, run, and test ( usual development cycle ) without any dependency on these benchmarks, or their infrastructure, essential working with a partial forest ( without the ?benchmark? repository ), then I can see the possible value in having a separate repository ( so I can skip cloning and updating it ). But, I?m not sure if that is a reasonable justification for a new repository, as it is probably at odds with your goals, or maybe not? > > -Chris > > On 2 Dec 2014, at 19:53, Staffan Friberg wrote: > >> Hi, >> >> (Adding the jdk9-dev list to increase the visibility of the discussion) >> >> With the multiple sub-repository commit mechanism improved I believe this might be less of an issue. JPRT can push JDK and HS changes at together and the same functionality should be possible to use for this as well. I wonder if the test issue earlier was that it was a completely separate repository outside of the JDK forest, and less of an issue when being part of the same forest as the JDK source code. Perhaps someone from SQE can chime? >> >> Otherwise the main reason for having a separate sub-repository on the top level is making it easier to find what benchmarks are available and have a single place to add new once avoid any risk of name duplication. JMH is superb in filtering during execution during runtime so running just a single test or a group of tests is very straight forward and the recommended way, rather than having multiple benchmark JARs. It also makes the build process easier as the building can be done using a single Makefile and a single benchmark JAR (actually two, one for JDK 8 compatible tests and one for JDK 9) that can be picked up by automatic performance testing. >> >> Cheers, >> Staffan >> >> On 12/02/2014 06:48 AM, roger riggs wrote: >>> Hi Staffan, >>> >>> An earlier issue was keeping tests in sync with the code under test, hence >>> the use of test directories within each repository. >>> I think a structure in which the benchmarks for some function and the function >>> itself are in the same repository that is easier to understand and maintain. >>> >>> $.02, Roger >>> >>> >>> On 12/1/2014 7:08 PM, Staffan Friberg wrote: >>>> Hi, >>>> >>>> Hopefully this is the right list for this discussion. >>>> >>>> As part of adding Microbenchmarks to the OpenJDK source tree, I'm trying to understand how we best would add the benchmark sources to the existing OpenJDK tree structure. >>>> >>>> Since the microbenchmark suite will cover all parts of the JDK, covering HotSpot, JDK libraries and Nashorn, it would be preferred to add the microbenchmark directory as a new top level directory. Something similar to the following structure. Having "benchmark" as the top-level directory would allow us to later add different types of benchmarks without colliding with the microbenchmark suite. >>>> >>>> / >>>> benchmark/microbenchmark/... >>>> hotspot/... >>>> jdk/... >>>> nashorn/... >>>> >>>> With this as the premise I can see the following 3 options for how this could be added to the source code layout >>>> >>>> 1. Part of jdk-root repository >>>> * Only makes sense if we want to move in a direction with fewer >>>> trees (and eventually a single tree) >>>> 2. Part of another already existing tree >>>> * Not sure if this is possible without converting and moving the >>>> directory to a subdirectory of that tree >>>> 3. New tree in the forest/tree structure >>>> * Most logical option as it follows the current setup and structure >>>> >>>> >>>> Anyone have any comments and/or concerns on the suggested directory location and the tree structure in option 3. >>>> >>>> Would the build-dev team be the right group to later help setup a new tree if decided to be the right way to go? >>>> >>>> Regards, >>>> Staffan >>>> From jonathan.gibbons at oracle.com Tue Dec 2 22:14:10 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 02 Dec 2014 14:14:10 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547E3854.3060705@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> Message-ID: <547E39B2.4050108@oracle.com> Staffan, I would also ask how many files are eventually likely to be involved. If it's tens of files up to low hundreds, then a top level dir makes sense. If it's tens of thousands of files, then a separate repo makes more sense. -- Jon On 12/02/2014 02:08 PM, Staffan Friberg wrote: > Hi Chris, > > Agree, there is no major reason this needs to be a new repository, as > I mentioned in the 3 options below it would work well without it. The > main thing I want to achieve is that the benchmarks are located on the > top level. The suite will contain benchmarks for all parts of the JDK > so having it in either jdk or hotspot doesn't feel like it makes > sense. If people agree on having it as folder in the top level JDK > repository I'm perfectly fine with that. > > As for building it will most likely not be of the general build > process for building the JDK (do not want to increase the compilation > time for anyone not requiring the benchmark suite). It would have its > own target 'build-microbenchmark' which would depend on > 'exploded-image', but not the reverse. > > //Staffan > > On 12/02/2014 01:23 PM, Chris Hegarty wrote: >> Staffan, >> >> Having all the benchmarks located in a single place makes sense to >> me, but this doesn?t necessarily mean that they need their own >> repository, in the forest. >> >> If I can build, run, and test ( usual development cycle ) without any >> dependency on these benchmarks, or their infrastructure, essential >> working with a partial forest ( without the ?benchmark? repository ), >> then I can see the possible value in having a separate repository ( >> so I can skip cloning and updating it ). But, I?m not sure if that is >> a reasonable justification for a new repository, as it is probably at >> odds with your goals, or maybe not? >> >> -Chris >> >> On 2 Dec 2014, at 19:53, Staffan Friberg >> wrote: >> >>> Hi, >>> >>> (Adding the jdk9-dev list to increase the visibility of the discussion) >>> >>> With the multiple sub-repository commit mechanism improved I believe >>> this might be less of an issue. JPRT can push JDK and HS changes at >>> together and the same functionality should be possible to use for >>> this as well. I wonder if the test issue earlier was that it was a >>> completely separate repository outside of the JDK forest, and less >>> of an issue when being part of the same forest as the JDK source >>> code. Perhaps someone from SQE can chime? >>> >>> Otherwise the main reason for having a separate sub-repository on >>> the top level is making it easier to find what benchmarks are >>> available and have a single place to add new once avoid any risk of >>> name duplication. JMH is superb in filtering during execution during >>> runtime so running just a single test or a group of tests is very >>> straight forward and the recommended way, rather than having >>> multiple benchmark JARs. It also makes the build process easier as >>> the building can be done using a single Makefile and a single >>> benchmark JAR (actually two, one for JDK 8 compatible tests and one >>> for JDK 9) that can be picked up by automatic performance testing. >>> >>> Cheers, >>> Staffan >>> >>> On 12/02/2014 06:48 AM, roger riggs wrote: >>>> Hi Staffan, >>>> >>>> An earlier issue was keeping tests in sync with the code under >>>> test, hence >>>> the use of test directories within each repository. >>>> I think a structure in which the benchmarks for some function and >>>> the function >>>> itself are in the same repository that is easier to understand and >>>> maintain. >>>> >>>> $.02, Roger >>>> >>>> >>>> On 12/1/2014 7:08 PM, Staffan Friberg wrote: >>>>> Hi, >>>>> >>>>> Hopefully this is the right list for this discussion. >>>>> >>>>> As part of adding Microbenchmarks to the OpenJDK source tree, I'm >>>>> trying to understand how we best would add the benchmark sources >>>>> to the existing OpenJDK tree structure. >>>>> >>>>> Since the microbenchmark suite will cover all parts of the JDK, >>>>> covering HotSpot, JDK libraries and Nashorn, it would be preferred >>>>> to add the microbenchmark directory as a new top level directory. >>>>> Something similar to the following structure. Having "benchmark" >>>>> as the top-level directory would allow us to later add different >>>>> types of benchmarks without colliding with the microbenchmark suite. >>>>> >>>>> / >>>>> benchmark/microbenchmark/... >>>>> hotspot/... >>>>> jdk/... >>>>> nashorn/... >>>>> >>>>> With this as the premise I can see the following 3 options for how >>>>> this could be added to the source code layout >>>>> >>>>> 1. Part of jdk-root repository >>>>> * Only makes sense if we want to move in a direction with fewer >>>>> trees (and eventually a single tree) >>>>> 2. Part of another already existing tree >>>>> * Not sure if this is possible without converting and moving the >>>>> directory to a subdirectory of that tree >>>>> 3. New tree in the forest/tree structure >>>>> * Most logical option as it follows the current setup and >>>>> structure >>>>> >>>>> >>>>> Anyone have any comments and/or concerns on the suggested >>>>> directory location and the tree structure in option 3. >>>>> >>>>> Would the build-dev team be the right group to later help setup a >>>>> new tree if decided to be the right way to go? >>>>> >>>>> Regards, >>>>> Staffan >>>>> > From staffan.friberg at oracle.com Tue Dec 2 22:27:27 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 02 Dec 2014 14:27:27 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547E39B2.4050108@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> <547E39B2.4050108@oracle.com> Message-ID: <547E3CCF.8040009@oracle.com> Hi Jon, As part of the initial set of benchmarks we hope to add as part of this JEP I'm guessing it will be around 200-300 files. This would grow overtime, but I believe we won't see tens of thousands of files, it is more likely it will be something like a 1000 files. //Staffan On 12/02/2014 02:14 PM, Jonathan Gibbons wrote: > Staffan, > > I would also ask how many files are eventually likely to be involved. > > If it's tens of files up to low hundreds, then a top level dir makes > sense. > > If it's tens of thousands of files, then a separate repo makes more > sense. > > -- Jon > > > On 12/02/2014 02:08 PM, Staffan Friberg wrote: >> Hi Chris, >> >> Agree, there is no major reason this needs to be a new repository, as >> I mentioned in the 3 options below it would work well without it. The >> main thing I want to achieve is that the benchmarks are located on >> the top level. The suite will contain benchmarks for all parts of the >> JDK so having it in either jdk or hotspot doesn't feel like it makes >> sense. If people agree on having it as folder in the top level JDK >> repository I'm perfectly fine with that. >> >> As for building it will most likely not be of the general build >> process for building the JDK (do not want to increase the compilation >> time for anyone not requiring the benchmark suite). It would have its >> own target 'build-microbenchmark' which would depend on >> 'exploded-image', but not the reverse. >> >> //Staffan >> >> On 12/02/2014 01:23 PM, Chris Hegarty wrote: >>> Staffan, >>> >>> Having all the benchmarks located in a single place makes sense to >>> me, but this doesn?t necessarily mean that they need their own >>> repository, in the forest. >>> >>> If I can build, run, and test ( usual development cycle ) without >>> any dependency on these benchmarks, or their infrastructure, >>> essential working with a partial forest ( without the ?benchmark? >>> repository ), then I can see the possible value in having a separate >>> repository ( so I can skip cloning and updating it ). But, I?m not >>> sure if that is a reasonable justification for a new repository, as >>> it is probably at odds with your goals, or maybe not? >>> >>> -Chris >>> >>> On 2 Dec 2014, at 19:53, Staffan Friberg >>> wrote: >>> >>>> Hi, >>>> >>>> (Adding the jdk9-dev list to increase the visibility of the >>>> discussion) >>>> >>>> With the multiple sub-repository commit mechanism improved I >>>> believe this might be less of an issue. JPRT can push JDK and HS >>>> changes at together and the same functionality should be possible >>>> to use for this as well. I wonder if the test issue earlier was >>>> that it was a completely separate repository outside of the JDK >>>> forest, and less of an issue when being part of the same forest as >>>> the JDK source code. Perhaps someone from SQE can chime? >>>> >>>> Otherwise the main reason for having a separate sub-repository on >>>> the top level is making it easier to find what benchmarks are >>>> available and have a single place to add new once avoid any risk of >>>> name duplication. JMH is superb in filtering during execution >>>> during runtime so running just a single test or a group of tests is >>>> very straight forward and the recommended way, rather than having >>>> multiple benchmark JARs. It also makes the build process easier as >>>> the building can be done using a single Makefile and a single >>>> benchmark JAR (actually two, one for JDK 8 compatible tests and one >>>> for JDK 9) that can be picked up by automatic performance testing. >>>> >>>> Cheers, >>>> Staffan >>>> >>>> On 12/02/2014 06:48 AM, roger riggs wrote: >>>>> Hi Staffan, >>>>> >>>>> An earlier issue was keeping tests in sync with the code under >>>>> test, hence >>>>> the use of test directories within each repository. >>>>> I think a structure in which the benchmarks for some function and >>>>> the function >>>>> itself are in the same repository that is easier to understand and >>>>> maintain. >>>>> >>>>> $.02, Roger >>>>> >>>>> >>>>> On 12/1/2014 7:08 PM, Staffan Friberg wrote: >>>>>> Hi, >>>>>> >>>>>> Hopefully this is the right list for this discussion. >>>>>> >>>>>> As part of adding Microbenchmarks to the OpenJDK source tree, I'm >>>>>> trying to understand how we best would add the benchmark sources >>>>>> to the existing OpenJDK tree structure. >>>>>> >>>>>> Since the microbenchmark suite will cover all parts of the JDK, >>>>>> covering HotSpot, JDK libraries and Nashorn, it would be >>>>>> preferred to add the microbenchmark directory as a new top level >>>>>> directory. Something similar to the following structure. Having >>>>>> "benchmark" as the top-level directory would allow us to later >>>>>> add different types of benchmarks without colliding with the >>>>>> microbenchmark suite. >>>>>> >>>>>> / >>>>>> benchmark/microbenchmark/... >>>>>> hotspot/... >>>>>> jdk/... >>>>>> nashorn/... >>>>>> >>>>>> With this as the premise I can see the following 3 options for >>>>>> how this could be added to the source code layout >>>>>> >>>>>> 1. Part of jdk-root repository >>>>>> * Only makes sense if we want to move in a direction with fewer >>>>>> trees (and eventually a single tree) >>>>>> 2. Part of another already existing tree >>>>>> * Not sure if this is possible without converting and moving >>>>>> the >>>>>> directory to a subdirectory of that tree >>>>>> 3. New tree in the forest/tree structure >>>>>> * Most logical option as it follows the current setup and >>>>>> structure >>>>>> >>>>>> >>>>>> Anyone have any comments and/or concerns on the suggested >>>>>> directory location and the tree structure in option 3. >>>>>> >>>>>> Would the build-dev team be the right group to later help setup a >>>>>> new tree if decided to be the right way to go? >>>>>> >>>>>> Regards, >>>>>> Staffan >>>>>> >> > From jonathan.gibbons at oracle.com Tue Dec 2 22:40:14 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 02 Dec 2014 14:40:14 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547E3CCF.8040009@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> <547E39B2.4050108@oracle.com> <547E3CCF.8040009@oracle.com> Message-ID: <547E3FCE.2010001@oracle.com> Staffan, That seems to put it on the low end for reasonably being its own repo, if you wanted that, at least, as indicated by the numbers. Here's the file counts for where we are now corba 1192 hotspot 4761 jaxp 2883 jaxws 3748 jdk 22776 langtools 6785 -- Jon On 12/02/2014 02:27 PM, Staffan Friberg wrote: > Hi Jon, > > As part of the initial set of benchmarks we hope to add as part of > this JEP I'm guessing it will be around 200-300 files. This would grow > overtime, but I believe we won't see tens of thousands of files, it is > more likely it will be something like a 1000 files. > > //Staffan > > On 12/02/2014 02:14 PM, Jonathan Gibbons wrote: >> Staffan, >> >> I would also ask how many files are eventually likely to be involved. >> >> If it's tens of files up to low hundreds, then a top level dir makes >> sense. >> >> If it's tens of thousands of files, then a separate repo makes more >> sense. >> >> -- Jon >> >> >> On 12/02/2014 02:08 PM, Staffan Friberg wrote: >>> Hi Chris, >>> >>> Agree, there is no major reason this needs to be a new repository, >>> as I mentioned in the 3 options below it would work well without it. >>> The main thing I want to achieve is that the benchmarks are located >>> on the top level. The suite will contain benchmarks for all parts of >>> the JDK so having it in either jdk or hotspot doesn't feel like it >>> makes sense. If people agree on having it as folder in the top level >>> JDK repository I'm perfectly fine with that. >>> >>> As for building it will most likely not be of the general build >>> process for building the JDK (do not want to increase the >>> compilation time for anyone not requiring the benchmark suite). It >>> would have its own target 'build-microbenchmark' which would depend >>> on 'exploded-image', but not the reverse. >>> >>> //Staffan >>> >>> On 12/02/2014 01:23 PM, Chris Hegarty wrote: >>>> Staffan, >>>> >>>> Having all the benchmarks located in a single place makes sense to >>>> me, but this doesn?t necessarily mean that they need their own >>>> repository, in the forest. >>>> >>>> If I can build, run, and test ( usual development cycle ) without >>>> any dependency on these benchmarks, or their infrastructure, >>>> essential working with a partial forest ( without the ?benchmark? >>>> repository ), then I can see the possible value in having a >>>> separate repository ( so I can skip cloning and updating it ). But, >>>> I?m not sure if that is a reasonable justification for a new >>>> repository, as it is probably at odds with your goals, or maybe not? >>>> >>>> -Chris >>>> >>>> On 2 Dec 2014, at 19:53, Staffan Friberg >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> (Adding the jdk9-dev list to increase the visibility of the >>>>> discussion) >>>>> >>>>> With the multiple sub-repository commit mechanism improved I >>>>> believe this might be less of an issue. JPRT can push JDK and HS >>>>> changes at together and the same functionality should be possible >>>>> to use for this as well. I wonder if the test issue earlier was >>>>> that it was a completely separate repository outside of the JDK >>>>> forest, and less of an issue when being part of the same forest as >>>>> the JDK source code. Perhaps someone from SQE can chime? >>>>> >>>>> Otherwise the main reason for having a separate sub-repository on >>>>> the top level is making it easier to find what benchmarks are >>>>> available and have a single place to add new once avoid any risk >>>>> of name duplication. JMH is superb in filtering during execution >>>>> during runtime so running just a single test or a group of tests >>>>> is very straight forward and the recommended way, rather than >>>>> having multiple benchmark JARs. It also makes the build process >>>>> easier as the building can be done using a single Makefile and a >>>>> single benchmark JAR (actually two, one for JDK 8 compatible tests >>>>> and one for JDK 9) that can be picked up by automatic performance >>>>> testing. >>>>> >>>>> Cheers, >>>>> Staffan >>>>> >>>>> On 12/02/2014 06:48 AM, roger riggs wrote: >>>>>> Hi Staffan, >>>>>> >>>>>> An earlier issue was keeping tests in sync with the code under >>>>>> test, hence >>>>>> the use of test directories within each repository. >>>>>> I think a structure in which the benchmarks for some function and >>>>>> the function >>>>>> itself are in the same repository that is easier to understand >>>>>> and maintain. >>>>>> >>>>>> $.02, Roger >>>>>> >>>>>> >>>>>> On 12/1/2014 7:08 PM, Staffan Friberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Hopefully this is the right list for this discussion. >>>>>>> >>>>>>> As part of adding Microbenchmarks to the OpenJDK source tree, >>>>>>> I'm trying to understand how we best would add the benchmark >>>>>>> sources to the existing OpenJDK tree structure. >>>>>>> >>>>>>> Since the microbenchmark suite will cover all parts of the JDK, >>>>>>> covering HotSpot, JDK libraries and Nashorn, it would be >>>>>>> preferred to add the microbenchmark directory as a new top level >>>>>>> directory. Something similar to the following structure. Having >>>>>>> "benchmark" as the top-level directory would allow us to later >>>>>>> add different types of benchmarks without colliding with the >>>>>>> microbenchmark suite. >>>>>>> >>>>>>> / >>>>>>> benchmark/microbenchmark/... >>>>>>> hotspot/... >>>>>>> jdk/... >>>>>>> nashorn/... >>>>>>> >>>>>>> With this as the premise I can see the following 3 options for >>>>>>> how this could be added to the source code layout >>>>>>> >>>>>>> 1. Part of jdk-root repository >>>>>>> * Only makes sense if we want to move in a direction with >>>>>>> fewer >>>>>>> trees (and eventually a single tree) >>>>>>> 2. Part of another already existing tree >>>>>>> * Not sure if this is possible without converting and >>>>>>> moving the >>>>>>> directory to a subdirectory of that tree >>>>>>> 3. New tree in the forest/tree structure >>>>>>> * Most logical option as it follows the current setup and >>>>>>> structure >>>>>>> >>>>>>> >>>>>>> Anyone have any comments and/or concerns on the suggested >>>>>>> directory location and the tree structure in option 3. >>>>>>> >>>>>>> Would the build-dev team be the right group to later help setup >>>>>>> a new tree if decided to be the right way to go? >>>>>>> >>>>>>> Regards, >>>>>>> Staffan >>>>>>> >>> >> > From christian.thalinger at oracle.com Tue Dec 2 22:45:53 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 2 Dec 2014 14:45:53 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547E3FCE.2010001@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> <547E39B2.4050108@oracle.com> <547E3CCF.8040009@oracle.com> <547E3FCE.2010001@oracle.com> Message-ID: > On Dec 2, 2014, at 2:40 PM, Jonathan Gibbons wrote: > > Staffan, > > That seems to put it on the low end for reasonably being its own repo, if you wanted that, at least, as indicated by the numbers. Do we really want more repositories? > > Here's the file counts for where we are now > > corba 1192 > hotspot 4761 > jaxp 2883 > jaxws 3748 > jdk 22776 > langtools 6785 > > -- Jon > > On 12/02/2014 02:27 PM, Staffan Friberg wrote: >> Hi Jon, >> >> As part of the initial set of benchmarks we hope to add as part of this JEP I'm guessing it will be around 200-300 files. This would grow overtime, but I believe we won't see tens of thousands of files, it is more likely it will be something like a 1000 files. >> >> //Staffan >> >> On 12/02/2014 02:14 PM, Jonathan Gibbons wrote: >>> Staffan, >>> >>> I would also ask how many files are eventually likely to be involved. >>> >>> If it's tens of files up to low hundreds, then a top level dir makes sense. >>> >>> If it's tens of thousands of files, then a separate repo makes more sense. >>> >>> -- Jon >>> >>> >>> On 12/02/2014 02:08 PM, Staffan Friberg wrote: >>>> Hi Chris, >>>> >>>> Agree, there is no major reason this needs to be a new repository, as I mentioned in the 3 options below it would work well without it. The main thing I want to achieve is that the benchmarks are located on the top level. The suite will contain benchmarks for all parts of the JDK so having it in either jdk or hotspot doesn't feel like it makes sense. If people agree on having it as folder in the top level JDK repository I'm perfectly fine with that. >>>> >>>> As for building it will most likely not be of the general build process for building the JDK (do not want to increase the compilation time for anyone not requiring the benchmark suite). It would have its own target 'build-microbenchmark' which would depend on 'exploded-image', but not the reverse. >>>> >>>> //Staffan >>>> >>>> On 12/02/2014 01:23 PM, Chris Hegarty wrote: >>>>> Staffan, >>>>> >>>>> Having all the benchmarks located in a single place makes sense to me, but this doesn?t necessarily mean that they need their own repository, in the forest. >>>>> >>>>> If I can build, run, and test ( usual development cycle ) without any dependency on these benchmarks, or their infrastructure, essential working with a partial forest ( without the ?benchmark? repository ), then I can see the possible value in having a separate repository ( so I can skip cloning and updating it ). But, I?m not sure if that is a reasonable justification for a new repository, as it is probably at odds with your goals, or maybe not? >>>>> >>>>> -Chris >>>>> >>>>> On 2 Dec 2014, at 19:53, Staffan Friberg wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> (Adding the jdk9-dev list to increase the visibility of the discussion) >>>>>> >>>>>> With the multiple sub-repository commit mechanism improved I believe this might be less of an issue. JPRT can push JDK and HS changes at together and the same functionality should be possible to use for this as well. I wonder if the test issue earlier was that it was a completely separate repository outside of the JDK forest, and less of an issue when being part of the same forest as the JDK source code. Perhaps someone from SQE can chime? >>>>>> >>>>>> Otherwise the main reason for having a separate sub-repository on the top level is making it easier to find what benchmarks are available and have a single place to add new once avoid any risk of name duplication. JMH is superb in filtering during execution during runtime so running just a single test or a group of tests is very straight forward and the recommended way, rather than having multiple benchmark JARs. It also makes the build process easier as the building can be done using a single Makefile and a single benchmark JAR (actually two, one for JDK 8 compatible tests and one for JDK 9) that can be picked up by automatic performance testing. >>>>>> >>>>>> Cheers, >>>>>> Staffan >>>>>> >>>>>> On 12/02/2014 06:48 AM, roger riggs wrote: >>>>>>> Hi Staffan, >>>>>>> >>>>>>> An earlier issue was keeping tests in sync with the code under test, hence >>>>>>> the use of test directories within each repository. >>>>>>> I think a structure in which the benchmarks for some function and the function >>>>>>> itself are in the same repository that is easier to understand and maintain. >>>>>>> >>>>>>> $.02, Roger >>>>>>> >>>>>>> >>>>>>> On 12/1/2014 7:08 PM, Staffan Friberg wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Hopefully this is the right list for this discussion. >>>>>>>> >>>>>>>> As part of adding Microbenchmarks to the OpenJDK source tree, I'm trying to understand how we best would add the benchmark sources to the existing OpenJDK tree structure. >>>>>>>> >>>>>>>> Since the microbenchmark suite will cover all parts of the JDK, covering HotSpot, JDK libraries and Nashorn, it would be preferred to add the microbenchmark directory as a new top level directory. Something similar to the following structure. Having "benchmark" as the top-level directory would allow us to later add different types of benchmarks without colliding with the microbenchmark suite. >>>>>>>> >>>>>>>> / >>>>>>>> benchmark/microbenchmark/... >>>>>>>> hotspot/... >>>>>>>> jdk/... >>>>>>>> nashorn/... >>>>>>>> >>>>>>>> With this as the premise I can see the following 3 options for how this could be added to the source code layout >>>>>>>> >>>>>>>> 1. Part of jdk-root repository >>>>>>>> * Only makes sense if we want to move in a direction with fewer >>>>>>>> trees (and eventually a single tree) >>>>>>>> 2. Part of another already existing tree >>>>>>>> * Not sure if this is possible without converting and moving the >>>>>>>> directory to a subdirectory of that tree >>>>>>>> 3. New tree in the forest/tree structure >>>>>>>> * Most logical option as it follows the current setup and structure >>>>>>>> >>>>>>>> >>>>>>>> Anyone have any comments and/or concerns on the suggested directory location and the tree structure in option 3. >>>>>>>> >>>>>>>> Would the build-dev team be the right group to later help setup a new tree if decided to be the right way to go? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Staffan >>>>>>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Tue Dec 2 22:48:22 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 02 Dec 2014 14:48:22 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> <547E39B2.4050108@oracle.com> <547E3CCF.8040009@oracle.com> <547E3FCE.2010001@oracle.com> Message-ID: <547E41B6.1000909@oracle.com> On 12/02/2014 02:45 PM, Christian Thalinger wrote: >> >On Dec 2, 2014, at 2:40 PM, Jonathan Gibbons wrote: >> > >> >Staffan, >> > >> >That seems to put it on the low end for reasonably being its own repo, if you wanted that, at least, as indicated by the numbers. > Do we really want more repositories? > Conversely, do we really want bigger repositories? :-) (The bike shed is that-a-way.) -- Jon From martinrb at google.com Tue Dec 2 22:53:17 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 2 Dec 2014 14:53:17 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547E41B6.1000909@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> <547E39B2.4050108@oracle.com> <547E3CCF.8040009@oracle.com> <547E3FCE.2010001@oracle.com> <547E41B6.1000909@oracle.com> Message-ID: On Tue, Dec 2, 2014 at 2:48 PM, Jonathan Gibbons wrote: >> Do we really want more repositories? >> > > Conversely, do we really want bigger repositories? :-) Yes, we want bigger repositories, not more repositories. Put the benchmarks into the existing repo test directories. Name them all FooBenchmark.java Make it easy to run them, the same way jtreg makes it easy to run tests. Alternatively, start a bench directory hierarchy parallel and organized identically to, existing test directories. > (The bike shed is that-a-way.) > > -- Jon From medi.montaseri at hds.com Wed Dec 3 02:25:58 2014 From: medi.montaseri at hds.com (Medi Montaseri) Date: Wed, 3 Dec 2014 02:25:58 +0000 Subject: Confirming JDK 8 GA version Message-ID: <923F21021934C74299CD42CCCD265DA117068B34@USINDEM101.corp.hds.com> Hi, Just wanted to confirm some issues: I am interested in building the latest (tip) of jdk8 GA release. 1- jdk8 GA is different from jdk8u (u is for updates), I should get the src from http://hg.openjdk.java.net/jdk8/jdk8 2- The latest tagged version of the src is "jdk8-b132 9106:43cb25339b55" 3- I confirm that I have the latest src (for GA) by running "hg tags" like unix> cd srcDir/jdk ; hg tags | head -2 tip 9107:687fd7c7986d jdk8-b132 9106:43cb25339b55 I go ahead and build everything and then run "java -version" and I see openjdk version "1.8.0-20141202" OpenJDK Runtime Environment (build 1.8.0-20141202-HDS-174701) OpenJDK 64-Bit Server VM (build 25.0-b70, mixed mode) Q- Why am I seeing "build 25.0-b70" ? Does this "b70" has anything to do with above "jdk8-b132" ? Thanks Medi From david.holmes at oracle.com Wed Dec 3 05:13:31 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 03 Dec 2014 15:13:31 +1000 Subject: Confirming JDK 8 GA version In-Reply-To: <923F21021934C74299CD42CCCD265DA117068B34@USINDEM101.corp.hds.com> References: <923F21021934C74299CD42CCCD265DA117068B34@USINDEM101.corp.hds.com> Message-ID: <547E9BFB.10205@oracle.com> On 3/12/2014 12:25 PM, Medi Montaseri wrote: > Hi, > > Just wanted to confirm some issues: > I am interested in building the latest (tip) of jdk8 GA release. > > 1- jdk8 GA is different from jdk8u (u is for updates), I should get the src from http://hg.openjdk.java.net/jdk8/jdk8 > 2- The latest tagged version of the src is "jdk8-b132 9106:43cb25339b55" > 3- I confirm that I have the latest src (for GA) by running "hg tags" like > unix> cd srcDir/jdk ; hg tags | head -2 > tip 9107:687fd7c7986d > jdk8-b132 9106:43cb25339b55 > > I go ahead and build everything and then run "java -version" and I see > > openjdk version "1.8.0-20141202" > OpenJDK Runtime Environment (build 1.8.0-20141202-HDS-174701) > OpenJDK 64-Bit Server VM (build 25.0-b70, mixed mode) > > Q- Why am I seeing "build 25.0-b70" ? Does this "b70" has anything to do with above "jdk8-b132" ? That is the hotspot version number and build number as used in the GA build of JDK 8. It is correct. java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode) David ----- > Thanks > Medi > From staffan.larsen at oracle.com Wed Dec 3 07:58:39 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 3 Dec 2014 08:58:39 +0100 Subject: build warnings In-Reply-To: <547E365C.6040609@oracle.com> References: <547E365C.6040609@oracle.com> Message-ID: <1EFC21D1-F5E5-4F30-8CD2-F852AC6C4645@oracle.com> These are warnings in the java.desktop module. I don?t know what the appropriate email list is for java.desktop discussions, but perhaps bringing it up there would be the right thing to do? /Staffan > On 2 dec 2014, at 22:59, Jonathan Gibbons wrote: > > Build folk, > > The build has always generated warnings (sigh!) but right now, the warnings look scarier than usual. > > In particular, when the build terminates, I get a couple of screenfuls of messages like this: > > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: In function ?SplashScreenThread?: > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9: warning: ignoring return value of ?pipe?, declared with attribute warn_unused_result [-Wunused-result] > pipe(splash->controlpipe); > ^ > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c: In function ?initFormat?: > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34: warning: ?numBits? may be used uninitialized in this function [-Wmaybe-uninitialized] > format->shift[i] = shift + numBits - i * 8 - 8; > ^ > > What would it take to have some sort of campaign to reduce build warnings like these? We've made good progress on lint and doclint warnings for Java code and doc comments; what does it take to start on native code warnings? > > -- Jon From erik.joelsson at oracle.com Wed Dec 3 08:33:34 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 03 Dec 2014 09:33:34 +0100 Subject: Confirming JDK 8 GA version In-Reply-To: <547E9BFB.10205@oracle.com> References: <923F21021934C74299CD42CCCD265DA117068B34@USINDEM101.corp.hds.com> <547E9BFB.10205@oracle.com> Message-ID: <547ECADE.4020506@oracle.com> The source/makefiles are not aware of the build number. It's assigned from an external source at the time of building a promoted build. If you want your version number to better match 8 GA, you will have to play around with the configure arguments --with-build-number and possibly --with-milestone. Also, as David pointed out, in JDK 8, hotspot has it's own numbering. /Erik On 2014-12-03 06:13, David Holmes wrote: > On 3/12/2014 12:25 PM, Medi Montaseri wrote: >> Hi, >> >> Just wanted to confirm some issues: >> I am interested in building the latest (tip) of jdk8 GA release. >> >> 1- jdk8 GA is different from jdk8u (u is for updates), I should get >> the src from http://hg.openjdk.java.net/jdk8/jdk8 >> 2- The latest tagged version of the src is >> "jdk8-b132 9106:43cb25339b55" >> 3- I confirm that I have the latest src (for GA) by running "hg tags" >> like >> unix> cd srcDir/jdk ; hg tags | head -2 >> tip 9107:687fd7c7986d >> jdk8-b132 9106:43cb25339b55 >> >> I go ahead and build everything and then run "java -version" and I see >> >> openjdk version "1.8.0-20141202" >> OpenJDK Runtime Environment (build 1.8.0-20141202-HDS-174701) >> OpenJDK 64-Bit Server VM (build 25.0-b70, mixed mode) >> >> Q- Why am I seeing "build 25.0-b70" ? Does this "b70" has anything to >> do with above "jdk8-b132" ? > > That is the hotspot version number and build number as used in the GA > build of JDK 8. It is correct. > > java version "1.8.0" > Java(TM) SE Runtime Environment (build 1.8.0-b132) > Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode) > > David > ----- > >> Thanks >> Medi >> From magnus.ihse.bursie at oracle.com Wed Dec 3 10:58:44 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 03 Dec 2014 11:58:44 +0100 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> <547E39B2.4050108@oracle.com> <547E3CCF.8040009@oracle.com> <547E3FCE.2010001@oracle.com> Message-ID: <547EECE4.9030809@oracle.com> On 2014-12-02 23:45, Christian Thalinger wrote: >> On Dec 2, 2014, at 2:40 PM, Jonathan Gibbons wrote: >> >> Staffan, >> >> That seems to put it on the low end for reasonably being its own repo, if you wanted that, at least, as indicated by the numbers. > Do we really want more repositories? As long as the number of repositories are around a dozen, one more or less does not really matter. But our model will probably not scale well with hundreds of repos (e.g. if someone would suggest that every module should reside in a separate repo). My suggestion is that the microbenchmarks are put in the top-level repo, if only for the reason that it seems fully possible to split them out to a separate repo some time in the future if it grows too much, but it seems much more unlikely that it will ever be moved back into the top-level repo if we realized it was a stupid idea to put it in a separate repo. /Magnus From magnus.ihse.bursie at oracle.com Wed Dec 3 11:09:00 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 03 Dec 2014 12:09:00 +0100 Subject: build warnings In-Reply-To: <547E365C.6040609@oracle.com> References: <547E365C.6040609@oracle.com> Message-ID: <547EEF4C.1000603@oracle.com> On 2014-12-02 22:59, Jonathan Gibbons wrote: > Build folk, > > The build has always generated warnings (sigh!) but right now, the > warnings look scarier than usual. > > In particular, when the build terminates, I get a couple of screenfuls > of messages like this: > > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: > In function ?SplashScreenThread?: > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9: > warning: ignoring return value of ?pipe?, declared with attribute > warn_unused_result [-Wunused-result] > pipe(splash->controlpipe); > ^ > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c: > In function ?initFormat?: > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34: > warning: ?numBits? may be used uninitialized in this function > [-Wmaybe-uninitialized] > format->shift[i] = shift + numBits - i * 8 - 8; > ^ > > What would it take to have some sort of campaign to reduce build > warnings like these? We've made good progress on lint and doclint > warnings for Java code and doc comments; what does it take to start on > native code warnings? Actually, I've already started on such a campain. ;-) I believe the way to go is: 1) disable all (or more or less all) of the current flood of warnings 2) open bugs for all disabled warnings on the corresponding components, indicating that the owner of the component should: a) fix the issue with the source code and re-enable the warning, or b) come up with a good reason why the warning is bad/broken and should be left disabled for that component. I have started on 1). I have a local forest which disables most of the warnings for linux builds. I'm about to move on to the other platforms as well, but other work came between. /Magnus From erik.joelsson at oracle.com Wed Dec 3 14:30:16 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 03 Dec 2014 15:30:16 +0100 Subject: RFR [JEP 220] Modular Run-Time Images - fix zero build In-Reply-To: <547F122A.2000705@zafena.se> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <547F122A.2000705@zafena.se> Message-ID: <547F1E78.8080709@oracle.com> Hello Xerxes, Thanks for the suggestion. I have created https://bugs.openjdk.java.net/browse/JDK-8066589 to track this issue. Unfortunately we won't have time to fix it before pushing JEP 220 to jdk9. I hope this won't inconvenience you too much. Your suggested patch does correctly highlight the problem areas, but will not work since gnu make does not accept shell logic outside of recipes or $(shell ...) constructs. /Erik On 2014-12-03 14:37, Xerxes R?nby wrote: > Hi Chris! > > The build changes introduced a new dependency that sa-jdi.jar is > always built. > > The sa-jdi.jar do not get built for Zero and Itanium builds. > Zero is built using the --with-jvm-interpreter=cpp > --with-jvm-variants=zero configure options. > > The sa-jdi.jar also do not exist if you use the --with-import-hotspot= > to import alternative OpenJDK JVM such as > a pre-compiled CACAO JVM or JamVM libjvm.so . > > I would suggest to change the jdk/make/Import.gmk and > jdk/make/gensrc/Gensrc-jdk.jdi.gmk to first check if sa-jdi.jar > exist before adding it to the SA_TARGETS and GENSRC_JDK_JDI something > like this: > > Index: openjdk-jdk9-b38/jdk/make/Import.gmk > =================================================================== > --- openjdk-jdk9-b38.orig/jdk/make/Import.gmk 2014-11-17 > 17:34:13.830175424 +0100 > +++ openjdk-jdk9-b38/jdk/make/Import.gmk 2014-11-18 > 09:10:25.420715300 +0100 > @@ -221,6 +221,8 @@ > # even if zip is already unpacked. > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services: > $(HOTSPOT_DIST)/lib/sa-jdi.jar > > +# sa-jdi.jar do not exist for Itanium and zero > +if [ -a $(HOTSPOT_DIST)/lib/sa-jdi.jar ] ; \ > SA_TARGETS += > $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \ > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services > > Index: openjdk-jdk9-b38/jdk/make/gensrc/Gensrc-jdk.jdi.gmk > =================================================================== > --- openjdk-jdk9-b38.orig/jdk/make/gensrc/Gensrc-jdk.jdi.gmk > 2014-11-18 08:57:26.504852865 +0100 > +++ openjdk-jdk9-b38/jdk/make/gensrc/Gensrc-jdk.jdi.gmk 2014-11-18 > 09:10:43.348804201 +0100 > @@ -78,12 +78,10 @@ > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector > $(install-file) > > +# sa-jdi.jar do not exist for Itanium and zero > +if [ -a $(HOTSPOT_DIST)/lib/sa-jdi.jar ] ; \ > GENSRC_JDK_JDI += > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector > \ > $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/META-INF/services/com.sun.jdi.connect.Connector > > > Cheers > Xerxes > > > >>> From: Chris Hegarty >>> Subject: RFR [JEP 220] Modular Run-Time Images >>> Date: 20 November 2014 21:39:14 GMT >>> To: jigsaw-dev , jdk9-dev >>> , build-dev , >>> Alan Bateman , Alex Buckley >>> , Chris Hegarty , >>> Erik Joelsson , Jonathan Gibbons >>> , Karen Kinnear >>> , "Jim Laskey (Oracle)" >>> , Magnus Ihse Bursie >>> , Mandy Chung >>> , Mark Reinhold , >>> Paul Sandoz , "A. Sundararajan" >>> >>> >>> This is a review request for the changes for JEP 220: Modular >>> Run-Time Images [1]. >>> >>> There are a number of individuals responsible for these changes. >>> Some, possibly not all, are explicitly listed in the 'To' section of >>> this mail, and they will help address any comments arising from this >>> review request. >>> >>> The new run-time image structure is defined in JEP 220 [1], and can >>> be seen as a result of building the staging forest [2], or in the >>> early access builds [3]. >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~chegar/8061971/00/ >>> >>> Due to the significant impact of these changes, a JDK 9 promotion >>> has been tentatively reserved for their integration. All comments >>> are welcome, although given the nature of the changes then we might >>> have to create separate issues in JIRA to address some of them later >>> in jdk9/dev. >>> >>> -Chris. >>> >>> [1] http://openjdk.java.net/jeps/220 >>> [2] http://hg.openjdk.java.net/jigsaw/m2/ >>> [3] http://openjdk.java.net/projects/jigsaw/ea > From pointo1d at gmail.com Wed Dec 3 14:47:00 2014 From: pointo1d at gmail.com (Dave Pointon) Date: Wed, 3 Dec 2014 14:47:00 +0000 Subject: RFR [JEP 220] Modular Run-Time Images - fix zero build In-Reply-To: <547F1E78.8080709@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <547F122A.2000705@zafena.se> <547F1E78.8080709@oracle.com> Message-ID: Hmmm , Would it not be possible to modify Xerxes' suggested patch to do something along the lines of ... # sa-jdi.jar do not exist for Itanium and zero ifeq ($(shell if test -a $(HOTSPOT_DIST)/lib/sa-jdi.jar; then echo N; fi),N) SA_TARGETS += \ $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \ $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services endif Just a thought -- Dave Pointon FIAP MBCS - ? contractor engaged by IBM? Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe On 3 December 2014 at 14:30, Erik Joelsson wrote: > Hello Xerxes, > > Thanks for the suggestion. I have created https://bugs.openjdk.java.net/ > browse/JDK-8066589 to track this issue. Unfortunately we won't have time > to fix it before pushing JEP 220 to jdk9. I hope this won't inconvenience > you too much. > > Your suggested patch does correctly highlight the problem areas, but will > not work since gnu make does not accept shell logic outside of recipes or > $(shell ...) constructs. > > /Erik > > ?? > From Alan.Bateman at oracle.com Wed Dec 3 15:23:25 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 03 Dec 2014 15:23:25 +0000 Subject: build warnings In-Reply-To: <1EFC21D1-F5E5-4F30-8CD2-F852AC6C4645@oracle.com> References: <547E365C.6040609@oracle.com> <1EFC21D1-F5E5-4F30-8CD2-F852AC6C4645@oracle.com> Message-ID: <547F2AED.6060702@oracle.com> On 03/12/2014 07:58, Staffan Larsen wrote: > These are warnings in the java.desktop module. I don?t know what the appropriate email list is for java.desktop discussions, but perhaps bringing it up there would be the right thing to do? > Most of the warnings that I see are in the AWT and 2D code and so awt-dev and 2d-dev would be the mailing lists to bring patches for review. -Alan From jonathan.gibbons at oracle.com Wed Dec 3 16:21:46 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 03 Dec 2014 08:21:46 -0800 Subject: build warnings In-Reply-To: <547EEF4C.1000603@oracle.com> References: <547E365C.6040609@oracle.com> <547EEF4C.1000603@oracle.com> Message-ID: <547F389A.8070908@oracle.com> On 12/03/2014 03:09 AM, Magnus Ihse Bursie wrote: > On 2014-12-02 22:59, Jonathan Gibbons wrote: >> Build folk, >> >> The build has always generated warnings (sigh!) but right now, the >> warnings look scarier than usual. >> >> In particular, when the build terminates, I get a couple of >> screenfuls of messages like this: >> >> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: >> In function ?SplashScreenThread?: >> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9: >> warning: ignoring return value of ?pipe?, declared with attribute >> warn_unused_result [-Wunused-result] >> pipe(splash->controlpipe); >> ^ >> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c: >> In function ?initFormat?: >> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34: >> warning: ?numBits? may be used uninitialized in this function >> [-Wmaybe-uninitialized] >> format->shift[i] = shift + numBits - i * 8 - 8; >> ^ >> >> What would it take to have some sort of campaign to reduce build >> warnings like these? We've made good progress on lint and doclint >> warnings for Java code and doc comments; what does it take to start >> on native code warnings? > > Actually, I've already started on such a campain. ;-) > > I believe the way to go is: > 1) disable all (or more or less all) of the current flood of warnings > 2) open bugs for all disabled warnings on the corresponding > components, indicating that the owner of the component should: > a) fix the issue with the source code and re-enable the warning, or > b) come up with a good reason why the warning is bad/broken and should > be left disabled for that component. > > I have started on 1). I have a local forest which disables most of the > warnings for linux builds. I'm about to move on to the other platforms > as well, but other work came between. > > /Magnus Magnus, Thank you for the update; it's great to hear this is being looked at. -- Jon From kellyohair at gmail.com Wed Dec 3 17:42:32 2014 From: kellyohair at gmail.com (Kelly O'Hair) Date: Wed, 3 Dec 2014 09:42:32 -0800 Subject: build warnings In-Reply-To: <547EEF4C.1000603@oracle.com> References: <547E365C.6040609@oracle.com> <547EEF4C.1000603@oracle.com> Message-ID: <5C1574F9-61E7-43D0-A76C-2DBD551B826A@gmail.com> On Dec 3, 2014, at 3:09 AM, Magnus Ihse Bursie wrote: > On 2014-12-02 22:59, Jonathan Gibbons wrote: >> Build folk, >> >> The build has always generated warnings (sigh!) but right now, the warnings look scarier than usual. >> >> In particular, when the build terminates, I get a couple of screenfuls of messages like this: >> >> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: In function ?SplashScreenThread?: >> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9: warning: ignoring return value of ?pipe?, declared with attribute warn_unused_result [-Wunused-result] >> pipe(splash->controlpipe); >> ^ >> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c: In function ?initFormat?: >> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34: warning: ?numBits? may be used uninitialized in this function [-Wmaybe-uninitialized] >> format->shift[i] = shift + numBits - i * 8 - 8; >> ^ >> >> What would it take to have some sort of campaign to reduce build warnings like these? We've made good progress on lint and doclint warnings for Java code and doc comments; what does it take to start on native code warnings? > > Actually, I've already started on such a campain. ;-) > > I believe the way to go is: > 1) disable all (or more or less all) of the current flood of warnings > 2) open bugs for all disabled warnings on the corresponding components, indicating that the owner of the component should: > a) fix the issue with the source code and re-enable the warning, or > b) come up with a good reason why the warning is bad/broken and should be left disabled for that component. > > I have started on 1). I have a local forest which disables most of the warnings for linux builds. I'm about to move on to the other platforms as well, but other work came between. > > /Magnus Speaking from a bit of experience, if you disable the warnings, odds are good that they will never get fixed because being disabled will be considered by some as "we have no warnings" and they will work on other things, like adding more code with more invisible disabled warnings. Granted some of the C/C++ compiler warnings are very dubious and of little value, but many are not. Disabling the less valuable warnings makes sense, but I would caution on disabling all warnings. Just my 2 cents... -kto From erik.joelsson at oracle.com Wed Dec 3 17:46:15 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 03 Dec 2014 18:46:15 +0100 Subject: RFR [JEP 220] Modular Run-Time Images - fix zero build In-Reply-To: References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <547F122A.2000705@zafena.se> <547F1E78.8080709@oracle.com> Message-ID: <547F4C67.6030608@oracle.com> Yes, it can be modified. My preferred variant for file existence checking in make is "ifneq ($(wildcard /path/to/file), )". Also, in Gensrc-jdk.jdi.gmk, I would probably like some other logical condition to check on than sa-jdi.jar. We will address this at some point soon. /Erik On 2014-12-03 15:47, Dave Pointon wrote: > Hmmm , > > Would it not be possible to modify Xerxes' suggested patch to do > something along the lines of ... > > # sa-jdi.jar do not exist for Itanium and zero > ifeq ($(shell if test -a $(HOTSPOT_DIST)/lib/sa-jdi.jar; then echo N; > fi),N) > SA_TARGETS += \ > $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \ > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa > .services > endif > > Just a thought > > -- > Dave Pointon FIAP MBCS - > ? contractor engaged by IBM? > > > Now I saw, tho' too late, the folly of beginning a work before we > count the cost and before we we judge rightly of our strength to go > thro' with it - Robinson Crusoe > > On 3 December 2014 at 14:30, Erik Joelsson > wrote: > > Hello Xerxes, > > Thanks for the suggestion. I have created > https://bugs.openjdk.java.net/browse/JDK-8066589 to track this > issue. Unfortunately we won't have time to fix it before pushing > JEP 220 to jdk9. I hope this won't inconvenience you too much. > > Your suggested patch does correctly highlight the problem areas, > but will not work since gnu make does not accept shell logic > outside of recipes or $(shell ...) constructs. > > /Erik > > ? ? > > From pointo1d at gmail.com Wed Dec 3 18:13:17 2014 From: pointo1d at gmail.com (Dave Pointon) Date: Wed, 3 Dec 2014 18:13:17 +0000 Subject: build warnings In-Reply-To: <5C1574F9-61E7-43D0-A76C-2DBD551B826A@gmail.com> References: <547E365C.6040609@oracle.com> <547EEF4C.1000603@oracle.com> <5C1574F9-61E7-43D0-A76C-2DBD551B826A@gmail.com> Message-ID: Amen to that Magnus - what possible motive can there be to fix invisible, benign 'problems' ? -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe On 3 December 2014 at 17:42, Kelly O'Hair wrote: > > On Dec 3, 2014, at 3:09 AM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > > > On 2014-12-02 22:59, Jonathan Gibbons wrote: > >> Build folk, > >> > >> The build has always generated warnings (sigh!) but right now, the > warnings look scarier than usual. > >> > >> In particular, when the build terminates, I get a couple of screenfuls > of messages like this: > >> > >> > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: > In function ?SplashScreenThread?: > >> > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9: > warning: ignoring return value of ?pipe?, declared with attribute > warn_unused_result [-Wunused-result] > >> pipe(splash->controlpipe); > >> ^ > >> > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c: > In function ?initFormat?: > >> > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34: > warning: ?numBits? may be used uninitialized in this function > [-Wmaybe-uninitialized] > >> format->shift[i] = shift + numBits - i * 8 - 8; > >> ^ > >> > >> What would it take to have some sort of campaign to reduce build > warnings like these? We've made good progress on lint and doclint warnings > for Java code and doc comments; what does it take to start on native code > warnings? > > > > Actually, I've already started on such a campain. ;-) > > > > I believe the way to go is: > > 1) disable all (or more or less all) of the current flood of warnings > > 2) open bugs for all disabled warnings on the corresponding components, > indicating that the owner of the component should: > > a) fix the issue with the source code and re-enable the warning, or > > b) come up with a good reason why the warning is bad/broken and should > be left disabled for that component. > > > > I have started on 1). I have a local forest which disables most of the > warnings for linux builds. I'm about to move on to the other platforms as > well, but other work came between. > > > > /Magnus > > Speaking from a bit of experience, if you disable the warnings, odds are > good that they will never get fixed because being disabled will be > considered by some as "we have no warnings" and they will work on other > things, like adding more code with more invisible disabled warnings. > Granted some of the C/C++ compiler warnings are very dubious and of little > value, but many are not. Disabling the less valuable warnings makes sense, > but I would caution on disabling all warnings. Just my 2 cents... > > -kto > > > From pointo1d at gmail.com Wed Dec 3 18:13:52 2014 From: pointo1d at gmail.com (Dave Pointon) Date: Wed, 3 Dec 2014 18:13:52 +0000 Subject: RFR [JEP 220] Modular Run-Time Images - fix zero build In-Reply-To: <547F4C67.6030608@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <547F122A.2000705@zafena.se> <547F1E78.8080709@oracle.com> <547F4C67.6030608@oracle.com> Message-ID: Yep , I like that even more, Erik :-) -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe On 3 December 2014 at 17:46, Erik Joelsson wrote: > Yes, it can be modified. My preferred variant for file existence checking > in make is "ifneq ($(wildcard /path/to/file), )". Also, in > Gensrc-jdk.jdi.gmk, I would probably like some other logical condition to > check on than sa-jdi.jar. We will address this at some point soon. > > /Erik > > On 2014-12-03 15:47, Dave Pointon wrote: > > Hmmm , > > Would it not be possible to modify Xerxes' suggested patch to do > something along the lines of ... > > # sa-jdi.jar do not exist for Itanium and zero > ifeq ($(shell if test -a $(HOTSPOT_DIST)/lib/sa-jdi.jar; then echo N; > fi),N) > SA_TARGETS += \ > $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \ > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services > endif > > Just a thought > > -- > Dave Pointon FIAP MBCS - > ? contractor engaged by IBM? > > > Now I saw, tho' too late, the folly of beginning a work before we count > the cost and before we we judge rightly of our strength to go thro' with it > - Robinson Crusoe > > On 3 December 2014 at 14:30, Erik Joelsson > wrote: > >> Hello Xerxes, >> >> Thanks for the suggestion. I have created >> https://bugs.openjdk.java.net/browse/JDK-8066589 to track this issue. >> Unfortunately we won't have time to fix it before pushing JEP 220 to jdk9. >> I hope this won't inconvenience you too much. >> >> Your suggested patch does correctly highlight the problem areas, but will >> not work since gnu make does not accept shell logic outside of recipes or >> $(shell ...) constructs. >> >> /Erik >> >> ? ? >> > > > From medi.montaseri at hds.com Wed Dec 3 20:54:07 2014 From: medi.montaseri at hds.com (Medi Montaseri) Date: Wed, 3 Dec 2014 20:54:07 +0000 Subject: Confirming JDK 8 GA version In-Reply-To: <547ECADE.4020506@oracle.com> References: <923F21021934C74299CD42CCCD265DA117068B34@USINDEM101.corp.hds.com> <547E9BFB.10205@oracle.com>,<547ECADE.4020506@oracle.com> Message-ID: <923F21021934C74299CD42CCCD265DA117069CCD@USINDEM101.corp.hds.com> Thanks David and Erik, A bit more confused...I don't know what hotspot is. I am aware of configure --with-build-number and --with-milestone and indeed use them....and that is why I get bin/java -version openjdk version "1.8.0-20141202" // note how this version is stamped with a date OpenJDK Runtime Environment (build 1.8.0-20141202-HDS-174701) // note how this portion is also decorated with date, label and more numbers OpenJDK 64-Bit Server VM (build 25.0-b70, mixed mode) ^^^^ /// what is this b70 The b70 makes me think that I am not working with the tip Let me ask the question another way... If I pull the latest and "hg tags" says b132 as in >> unix> cd srcDir/jdk ; hg tags | head -2 >> tip 9107:687fd7c7986d >> jdk8-b132 9106:43cb25339b55 >> Can I then be sure that I am indeed working with the tip...? David...you see how yours is showing the b132 > java version "1.8.0" > Java(TM) SE Runtime Environment (build 1.8.0-b132) // look there is the b132 thing -b132 > Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode) > Again, I need to make sure I have the latest and be able to query some binary (java or javac) to show that it is the latest. Thanks Medi ________________________________________ From: Erik Joelsson [erik.joelsson at oracle.com] Sent: Wednesday, December 03, 2014 12:33 AM To: David Holmes; Medi Montaseri; build-dev at openjdk.java.net Subject: Re: Confirming JDK 8 GA version The source/makefiles are not aware of the build number. It's assigned from an external source at the time of building a promoted build. If you want your version number to better match 8 GA, you will have to play around with the configure arguments --with-build-number and possibly --with-milestone. Also, as David pointed out, in JDK 8, hotspot has it's own numbering. /Erik On 2014-12-03 06:13, David Holmes wrote: > On 3/12/2014 12:25 PM, Medi Montaseri wrote: >> Hi, >> >> Just wanted to confirm some issues: >> I am interested in building the latest (tip) of jdk8 GA release. >> >> 1- jdk8 GA is different from jdk8u (u is for updates), I should get >> the src from http://hg.openjdk.java.net/jdk8/jdk8 >> 2- The latest tagged version of the src is >> "jdk8-b132 9106:43cb25339b55" >> 3- I confirm that I have the latest src (for GA) by running "hg tags" >> like >> unix> cd srcDir/jdk ; hg tags | head -2 >> tip 9107:687fd7c7986d >> jdk8-b132 9106:43cb25339b55 >> >> I go ahead and build everything and then run "java -version" and I see >> >> openjdk version "1.8.0-20141202" >> OpenJDK Runtime Environment (build 1.8.0-20141202-HDS-174701) >> OpenJDK 64-Bit Server VM (build 25.0-b70, mixed mode) >> >> Q- Why am I seeing "build 25.0-b70" ? Does this "b70" has anything to >> do with above "jdk8-b132" ? > > That is the hotspot version number and build number as used in the GA > build of JDK 8. It is correct. > > java version "1.8.0" > Java(TM) SE Runtime Environment (build 1.8.0-b132) > Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode) > > David > ----- > >> Thanks >> Medi >> From david.holmes at oracle.com Thu Dec 4 03:16:30 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 04 Dec 2014 13:16:30 +1000 Subject: [8u60] RFR: 8038189: Add cross-platform compact profiles support In-Reply-To: <547D3F09.5010308@oracle.com> References: <547BB1C4.1000303@oracle.com> <547C3296.8000000@oracle.com> <547D3F09.5010308@oracle.com> Message-ID: <547FD20E.9020604@oracle.com> Updated webrev: http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk.v2/ Only changes are to profile-includes.txt. Thanks, David On 2/12/2014 2:24 PM, David Holmes wrote: > Erik, > > Many thanks for the makefile macro wizardry! I will incorporate, test > and return with an updated webreb. > > David > > On 1/12/2014 7:19 PM, Erik Joelsson wrote: >> Hello David, >> >> Most of it looks good, but profile-includes.txt could certainly benefit >> from some reduction in duplication. (Aside from the extension of the >> file itself, which I find a bit weird, but it's already there.) The two >> common structures that I can see are: >> 1. Expanding debuginfo files for macosx. >> 2. Assigning/expanding libraries to the correct variable. >> >> For macosx debuginfo expanding, I would define a macro to something like >> this: >> >> # Expand the contents of the .dSYM directories on macosx. >> # Param 1 - debug files list >> # Param 2 - libraries list >> define expand-debuginfo >> $(if $(and $(filter-out true, $(ZIP_DEBUGINFO_FILES)), $(filter >> macosx, $(OPENJDK_TARGET_OS))), \ >> $(foreach i, $1, $(addsuffix /Contents/Info.plist, $i)) \ >> $(foreach i, $2, $(addsuffix /Contents/Resources/DWARF/$i, >> $(filter $i.%, $1))), \ >> $1) >> endef >> >> And use it like this: >> >> PROFILE_1_DEBUG_FILES := $(call expand-debuginfo, >> $(PROFILE_1_DEBUG_FILES), $(PROFILE_1_LIBRARIES)) >> >> Filtering out jsig can be done on the parameters at the macro call. >> >> For the conditional addprefix of OPENJDK_TARGET_CPU_LEGACY_LIB, I would >> do something like: >> >> ifeq (, $(findstring $(OPENJDK_TARGET_OS), windows macosx)) >> LIB_SUBDIR := $(OPENJDK_TARGET_CPU_LEGACY_LIB)/ >> else >> LIB_SUBDIR := >> endif >> >> And then always assign PROFILE_*_JRE_LIB_FILES with $(addprefix >> $(LIB_SUBDIR), ...). The conditional on Windows for assigning to >> ...BIN_FILES or ...LIB_FILES I would leave in place since I don't think >> a macro solution would make it easier to understand. >> >> /Erik >> >> >> On 2014-12-01 01:09, David Holmes wrote: >>> Main bug is 8038189 but that is a closed bug, the open backport issue >>> is: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8066200 >>> >>> Compact Profiles support was added in 8, but only for the Linux >>> platform. I've now generalized this support to all the other >>> platforms. This is an 8u only change, targetting 8u60, as soon as the >>> jdk8u/dev starts accepting things for 8u60. >>> >>> The changes are not that extensive - mostly generalizing the lists and >>> accounting for different platforms putting files into different places >>> (jre/lib/ vs jre/lib vs jre/bin). It isn't necessary to produce >>> detailed per-platform lists as files that don't exist simply don't get >>> copied; but when files are obviously platform specific then I add them >>> under suitable guards. >>> >>> The biggest complexity comes from the debuginfo files, and in >>> particular unzipped debuginfo files. This accounts for the bulk of the >>> changes in profiles-includes.txt, as we try to identify the set of >>> debug files that might exist for each library (and OSX is the main >>> complication due to the .dSYM directory because the existing rules >>> only copy files not directories). Suggestions for reducing the >>> duplicated patterns would be appreciated. >>> >>> Platform specific contents were determined in conjunction with >>> examination of what Jigsaw is using in JDK 9 for the base module. >>> >>> I tested all the main platforms (Windows, Linux, Solaris and OSX) and >>> with/without zipping of debuginfo files. Note that Windows builds will >>> not work with unzipped debuginfo files due to 8025936, but I checked >>> that multiple debug info files were expanded into the right set of >>> targets. >>> >>> webrevs: >>> >>> http://cr.openjdk.java.net/~dholmes/8038189/webrev.top/ >>> >>> make/Main.gmk: >>> - Remove the os-check that constrained profiles to linux >>> >>> http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk/ >>> >>> make/CreateJars.gmk: >>> - Check for empty variables (Solaris doesn't like them) >>> - Fix # # comments >>> - Add explicit targets for the beanless classes with $ in them (the % >>> substitution doesn't work on all platforms when $ is also present) >>> >>> make/Images.gmk >>> - Don't filter out server VM from compact profiles >>> >>> make/Import.gmk >>> - Add Info.plist to the exported files (for unzipped debuginfo files >>> - this is a general fix not profiles specific so may warrant its own CR) >>> >>> make/Profiles.gmk >>> - Remove linux-only comment >>> >>> make/Tools.gmk >>> - Fix tool definitions to use $(PATH_SEP) and quote cp entries >>> >>> make/profile-includes.txt >>> - Bulk of changes as described above >>> >>> make/profile-rtjar-includes.txt >>> - Additional packages that exist on OSX only (but don't need to be >>> conditionally added) >>> - NOTE: if AIX or other platform add platform specific packages not >>> already included by an enclosing package, then they will also need to >>> be added >>> >>> Thanks, >>> David >> From erik.joelsson at oracle.com Thu Dec 4 08:50:27 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 04 Dec 2014 09:50:27 +0100 Subject: Confirming JDK 8 GA version In-Reply-To: <923F21021934C74299CD42CCCD265DA117069CCD@USINDEM101.corp.hds.com> References: <923F21021934C74299CD42CCCD265DA117068B34@USINDEM101.corp.hds.com> <547E9BFB.10205@oracle.com>, <547ECADE.4020506@oracle.com> <923F21021934C74299CD42CCCD265DA117069CCD@USINDEM101.corp.hds.com> Message-ID: <54802053.4030206@oracle.com> On 2014-12-03 21:54, Medi Montaseri wrote: > Thanks David and Erik, > > A bit more confused...I don't know what hotspot is. Hotspot is the jvm, basically libjvm.so (and a few of the support libs) and has historically been treated as a separate project from the rest of the jdk. Because of that it has its own version string. When you run java -version in jdk8, you see three lines. The last one that says "VM" belongs to Hotspot. It ignores the input from configure. > I am aware of configure --with-build-number and --with-milestone and indeed use them....and that is why I get > > bin/java -version > openjdk version "1.8.0-20141202" // note how this version is stamped with a date > OpenJDK Runtime Environment (build 1.8.0-20141202-HDS-174701) // note how this portion is also decorated with date, label and more numbers > OpenJDK 64-Bit Server VM (build 25.0-b70, mixed mode) > ^^^^ /// what is this b70 > > The b70 makes me think that I am not working with the tip Look at that line with "VM" and "b70" and compare it to the same line from jdk8 GA. They are the exact same. > Let me ask the question another way... > > If I pull the latest and "hg tags" says b132 as in > >>> unix> cd srcDir/jdk ; hg tags | head -2 >>> tip 9107:687fd7c7986d >>> jdk8-b132 9106:43cb25339b55 >>> > Can I then be sure that I am indeed working with the tip...? AFAIK yes. > > David...you see how yours is showing the b132 > >> java version "1.8.0" >> Java(TM) SE Runtime Environment (build 1.8.0-b132) // look there is the b132 thing -b132 >> Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode) Yes, this shows b132, in the line that is only defined by configure arguments, and that you are setting to something else. /Erik > Again, I need to make sure I have the latest and be able to query some binary (java or javac) to show that it is the latest. > > Thanks > Medi > > ________________________________________ > From: Erik Joelsson [erik.joelsson at oracle.com] > Sent: Wednesday, December 03, 2014 12:33 AM > To: David Holmes; Medi Montaseri; build-dev at openjdk.java.net > Subject: Re: Confirming JDK 8 GA version > > The source/makefiles are not aware of the build number. It's assigned > from an external source at the time of building a promoted build. If you > want your version number to better match 8 GA, you will have to play > around with the configure arguments --with-build-number and possibly > --with-milestone. > > Also, as David pointed out, in JDK 8, hotspot has it's own numbering. > > /Erik > > On 2014-12-03 06:13, David Holmes wrote: >> On 3/12/2014 12:25 PM, Medi Montaseri wrote: >>> Hi, >>> >>> Just wanted to confirm some issues: >>> I am interested in building the latest (tip) of jdk8 GA release. >>> >>> 1- jdk8 GA is different from jdk8u (u is for updates), I should get >>> the src from http://hg.openjdk.java.net/jdk8/jdk8 >>> 2- The latest tagged version of the src is >>> "jdk8-b132 9106:43cb25339b55" >>> 3- I confirm that I have the latest src (for GA) by running "hg tags" >>> like >>> unix> cd srcDir/jdk ; hg tags | head -2 >>> tip 9107:687fd7c7986d >>> jdk8-b132 9106:43cb25339b55 >>> >>> I go ahead and build everything and then run "java -version" and I see >>> >>> openjdk version "1.8.0-20141202" >>> OpenJDK Runtime Environment (build 1.8.0-20141202-HDS-174701) >>> OpenJDK 64-Bit Server VM (build 25.0-b70, mixed mode) >>> >>> Q- Why am I seeing "build 25.0-b70" ? Does this "b70" has anything to >>> do with above "jdk8-b132" ? >> That is the hotspot version number and build number as used in the GA >> build of JDK 8. It is correct. >> >> java version "1.8.0" >> Java(TM) SE Runtime Environment (build 1.8.0-b132) >> Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode) >> >> David >> ----- >> >>> Thanks >>> Medi >>> From erik.joelsson at oracle.com Thu Dec 4 08:53:28 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 04 Dec 2014 09:53:28 +0100 Subject: [8u60] RFR: 8038189: Add cross-platform compact profiles support In-Reply-To: <547FD20E.9020604@oracle.com> References: <547BB1C4.1000303@oracle.com> <547C3296.8000000@oracle.com> <547D3F09.5010308@oracle.com> <547FD20E.9020604@oracle.com> Message-ID: <54802108.5030300@oracle.com> Looks good to me. /Erik On 2014-12-04 04:16, David Holmes wrote: > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk.v2/ > > Only changes are to profile-includes.txt. > > Thanks, > David > > On 2/12/2014 2:24 PM, David Holmes wrote: >> Erik, >> >> Many thanks for the makefile macro wizardry! I will incorporate, test >> and return with an updated webreb. >> >> David >> >> On 1/12/2014 7:19 PM, Erik Joelsson wrote: >>> Hello David, >>> >>> Most of it looks good, but profile-includes.txt could certainly benefit >>> from some reduction in duplication. (Aside from the extension of the >>> file itself, which I find a bit weird, but it's already there.) The two >>> common structures that I can see are: >>> 1. Expanding debuginfo files for macosx. >>> 2. Assigning/expanding libraries to the correct variable. >>> >>> For macosx debuginfo expanding, I would define a macro to something >>> like >>> this: >>> >>> # Expand the contents of the .dSYM directories on macosx. >>> # Param 1 - debug files list >>> # Param 2 - libraries list >>> define expand-debuginfo >>> $(if $(and $(filter-out true, $(ZIP_DEBUGINFO_FILES)), $(filter >>> macosx, $(OPENJDK_TARGET_OS))), \ >>> $(foreach i, $1, $(addsuffix /Contents/Info.plist, $i)) \ >>> $(foreach i, $2, $(addsuffix /Contents/Resources/DWARF/$i, >>> $(filter $i.%, $1))), \ >>> $1) >>> endef >>> >>> And use it like this: >>> >>> PROFILE_1_DEBUG_FILES := $(call expand-debuginfo, >>> $(PROFILE_1_DEBUG_FILES), $(PROFILE_1_LIBRARIES)) >>> >>> Filtering out jsig can be done on the parameters at the macro call. >>> >>> For the conditional addprefix of OPENJDK_TARGET_CPU_LEGACY_LIB, I would >>> do something like: >>> >>> ifeq (, $(findstring $(OPENJDK_TARGET_OS), windows macosx)) >>> LIB_SUBDIR := $(OPENJDK_TARGET_CPU_LEGACY_LIB)/ >>> else >>> LIB_SUBDIR := >>> endif >>> >>> And then always assign PROFILE_*_JRE_LIB_FILES with $(addprefix >>> $(LIB_SUBDIR), ...). The conditional on Windows for assigning to >>> ...BIN_FILES or ...LIB_FILES I would leave in place since I don't think >>> a macro solution would make it easier to understand. >>> >>> /Erik >>> >>> >>> On 2014-12-01 01:09, David Holmes wrote: >>>> Main bug is 8038189 but that is a closed bug, the open backport issue >>>> is: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8066200 >>>> >>>> Compact Profiles support was added in 8, but only for the Linux >>>> platform. I've now generalized this support to all the other >>>> platforms. This is an 8u only change, targetting 8u60, as soon as the >>>> jdk8u/dev starts accepting things for 8u60. >>>> >>>> The changes are not that extensive - mostly generalizing the lists and >>>> accounting for different platforms putting files into different places >>>> (jre/lib/ vs jre/lib vs jre/bin). It isn't necessary to produce >>>> detailed per-platform lists as files that don't exist simply don't get >>>> copied; but when files are obviously platform specific then I add them >>>> under suitable guards. >>>> >>>> The biggest complexity comes from the debuginfo files, and in >>>> particular unzipped debuginfo files. This accounts for the bulk of the >>>> changes in profiles-includes.txt, as we try to identify the set of >>>> debug files that might exist for each library (and OSX is the main >>>> complication due to the .dSYM directory because the existing rules >>>> only copy files not directories). Suggestions for reducing the >>>> duplicated patterns would be appreciated. >>>> >>>> Platform specific contents were determined in conjunction with >>>> examination of what Jigsaw is using in JDK 9 for the base module. >>>> >>>> I tested all the main platforms (Windows, Linux, Solaris and OSX) and >>>> with/without zipping of debuginfo files. Note that Windows builds will >>>> not work with unzipped debuginfo files due to 8025936, but I checked >>>> that multiple debug info files were expanded into the right set of >>>> targets. >>>> >>>> webrevs: >>>> >>>> http://cr.openjdk.java.net/~dholmes/8038189/webrev.top/ >>>> >>>> make/Main.gmk: >>>> - Remove the os-check that constrained profiles to linux >>>> >>>> http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk/ >>>> >>>> make/CreateJars.gmk: >>>> - Check for empty variables (Solaris doesn't like them) >>>> - Fix # # comments >>>> - Add explicit targets for the beanless classes with $ in them (the % >>>> substitution doesn't work on all platforms when $ is also present) >>>> >>>> make/Images.gmk >>>> - Don't filter out server VM from compact profiles >>>> >>>> make/Import.gmk >>>> - Add Info.plist to the exported files (for unzipped debuginfo files >>>> - this is a general fix not profiles specific so may warrant its >>>> own CR) >>>> >>>> make/Profiles.gmk >>>> - Remove linux-only comment >>>> >>>> make/Tools.gmk >>>> - Fix tool definitions to use $(PATH_SEP) and quote cp entries >>>> >>>> make/profile-includes.txt >>>> - Bulk of changes as described above >>>> >>>> make/profile-rtjar-includes.txt >>>> - Additional packages that exist on OSX only (but don't need to be >>>> conditionally added) >>>> - NOTE: if AIX or other platform add platform specific packages not >>>> already included by an enclosing package, then they will also need to >>>> be added >>>> >>>> Thanks, >>>> David >>> From Alan.Bateman at oracle.com Thu Dec 4 13:48:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Dec 2014 13:48:55 +0000 Subject: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint In-Reply-To: <54805A8E.4030806@zafena.se> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <54805A8E.4030806@zafena.se> Message-ID: <54806647.5050300@oracle.com> On 04/12/2014 12:58, Xerxes R?nby wrote: > The footprint of the compact profiles have been inflated by ~12Mb each > after the JEP 220 changes. > > before > # du -s -h j2re-compact1-image > 17.9M j2re-compact1-image > # du -s -h j2re-compact2-image > 28.7M j2re-compact2-image > # du -s -h j2re-compact3-image > 35.5M j2re-compact3-image > > after > # du -s -h jre-compact1 > 31.3M jre-compact1 > # du -s -h jre-compact2 > 41.5M jre-compact2 > # du -s -h jre-compact3 > 47.4M jre-compact3 > > The attached file compact1.diff.tar.gz contains the list diff of the > files bundled in the > j2re-compact1-image/lib/rt.jar compared to jre-compact1/lib/*.jimage > most of the class diff is located in > > com/sun/security/ntlm > com/sun/crypto > javax/crypto > sun/net/www/protocol/http/ntlm > sun/net/www/protocol/ftp > sun/net/www/protocol/mailto > sun/net/ftp > sun/net/smtp > sun/net/dns > sun/util/resources <- a lot of extra internationalized classes > sun/security/ssl > sun/security/ec > sun/security/pkcs11 > sun/text/resources <- a lot of extra internationalized classes The release file in the top directory of the runtime image gives a good indication as to what is going on. If you look at the value of the MODULES key then you'll the see the modules that are actually linked in. For jre-compact1 then you should see a line like this: MODULES="java.base jdk.localedata java.scripting java.logging java.compact1 jdk.crypto.ec jdk.crypto.pkcs11" The java.* modules are the modules that make up compact1, the jdk.* modules are additional service providers linked into the image. The service providers aren't strictly required to be there, we've just chosen to include them so that "profiles" make target gives us images that approximately correspond to what we had previously. If you want to play around with leaving them out then look in make/Images.gmk and COMPACT_EXTRA_MODULES. Going forward then I expect we will have a tool that will allow for a lot more flexibility to create images with just the modules that you want (and their transitive dependences of course). So I think the bulk of the difference that you are seeing is explained by the service providers and mostly jdk.localedata. That module is big and contains all of non-US_en JRE locale data and all of the CLDR data. We still need to figure out what how to split this, you might recall the discussion on i18n-dev and jigsaw-dev where they was some recent discussion on this. It's also listed in JEP 200 as an open issue. So when comparing to JDK 8 or previous JDK 9 compact profile builds then think of the new images has having the equivalent of both localedata.jar and cldrdata.jar present. If you edit COMPACT_EXTRA_MODULES to remove jdk.localdata.jar then it should make it easier to compare. Another thing to point out is that rt.jar isn't everything in the legacy image. You need to take account of jce.jar, jsse.jar and ext/sunjce_provider.jar. That should explain the javax.crypto, com.sun.crypto and sun.security.ssl packages in your list. Another thing to mention is the java.base module currently contains a few legacy items that we previously stripped out of the profiles builds in JDK 8. We still need to figure out what to do with these. The ftp and smtp protocol handlers come to mind, also the NTLM htto authentication scheme. At one point we have a "compat" module for legacy stuff that people might want for compatibility reasons. So expect some tweaking here, we know people focused on footprint will not thank us for bringing back legacy stuff. A few final point to mention. (a) there are a few additional launchers (and maybe debug info/diz files if build with those) that were not there previously. This is a consequence of modularization where modules with launchers and where the classes for those launchers were previously in tools.jar. (b) there are some additional classes that didn't previously exist in JDK 9, this is to support the new image format. I expect some churn with those over the next few months. So hopefully this helps to explain what you are seeing. I think folks might be interested in see j2re-image vs. jre and j2sdk-image vs. jdk sizes too. -Alan. From naoto.sato at oracle.com Thu Dec 4 16:38:48 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 04 Dec 2014 08:38:48 -0800 Subject: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint In-Reply-To: <54806647.5050300@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <54805A8E.4030806@zafena.se> <54806647.5050300@oracle.com> Message-ID: <54808E18.4070403@oracle.com> Quick question. Why is jdk.localedata module included in the compact profiles? The data there used to be in lib/ext/localedata.jar and lib/ext/cldrdata.jar which weren't included in those compact profiles. Naoto On 12/4/14, 5:48 AM, Alan Bateman wrote: > On 04/12/2014 12:58, Xerxes R?nby wrote: >> The footprint of the compact profiles have been inflated by ~12Mb each >> after the JEP 220 changes. >> >> before >> # du -s -h j2re-compact1-image >> 17.9M j2re-compact1-image >> # du -s -h j2re-compact2-image >> 28.7M j2re-compact2-image >> # du -s -h j2re-compact3-image >> 35.5M j2re-compact3-image >> >> after >> # du -s -h jre-compact1 >> 31.3M jre-compact1 >> # du -s -h jre-compact2 >> 41.5M jre-compact2 >> # du -s -h jre-compact3 >> 47.4M jre-compact3 >> >> The attached file compact1.diff.tar.gz contains the list diff of the >> files bundled in the >> j2re-compact1-image/lib/rt.jar compared to jre-compact1/lib/*.jimage >> most of the class diff is located in >> >> com/sun/security/ntlm >> com/sun/crypto >> javax/crypto >> sun/net/www/protocol/http/ntlm >> sun/net/www/protocol/ftp >> sun/net/www/protocol/mailto >> sun/net/ftp >> sun/net/smtp >> sun/net/dns >> sun/util/resources <- a lot of extra internationalized classes >> sun/security/ssl >> sun/security/ec >> sun/security/pkcs11 >> sun/text/resources <- a lot of extra internationalized classes > > The release file in the top directory of the runtime image gives a good > indication as to what is going on. If you look at the value of the > MODULES key then you'll the see the modules that are actually linked in. > For jre-compact1 then you should see a line like this: > > MODULES="java.base jdk.localedata java.scripting java.logging > java.compact1 jdk.crypto.ec jdk.crypto.pkcs11" > > The java.* modules are the modules that make up compact1, the jdk.* > modules are additional service providers linked into the image. The > service providers aren't strictly required to be there, we've just > chosen to include them so that "profiles" make target gives us images > that approximately correspond to what we had previously. If you want to > play around with leaving them out then look in make/Images.gmk and > COMPACT_EXTRA_MODULES. Going forward then I expect we will have a tool > that will allow for a lot more flexibility to create images with just > the modules that you want (and their transitive dependences of course). > > So I think the bulk of the difference that you are seeing is explained > by the service providers and mostly jdk.localedata. That module is big > and contains all of non-US_en JRE locale data and all of the CLDR data. > We still need to figure out what how to split this, you might recall the > discussion on i18n-dev and jigsaw-dev where they was some recent > discussion on this. It's also listed in JEP 200 as an open issue. > > So when comparing to JDK 8 or previous JDK 9 compact profile builds then > think of the new images has having the equivalent of both localedata.jar > and cldrdata.jar present. If you edit COMPACT_EXTRA_MODULES to remove > jdk.localdata.jar then it should make it easier to compare. > > Another thing to point out is that rt.jar isn't everything in the legacy > image. You need to take account of jce.jar, jsse.jar and > ext/sunjce_provider.jar. That should explain the javax.crypto, > com.sun.crypto and sun.security.ssl packages in your list. > > Another thing to mention is the java.base module currently contains a > few legacy items that we previously stripped out of the profiles builds > in JDK 8. We still need to figure out what to do with these. The ftp and > smtp protocol handlers come to mind, also the NTLM htto authentication > scheme. At one point we have a "compat" module for legacy stuff that > people might want for compatibility reasons. So expect some tweaking > here, we know people focused on footprint will not thank us for bringing > back legacy stuff. > > A few final point to mention. (a) there are a few additional launchers > (and maybe debug info/diz files if build with those) that were not there > previously. This is a consequence of modularization where modules with > launchers and where the classes for those launchers were previously in > tools.jar. (b) there are some additional classes that didn't previously > exist in JDK 9, this is to support the new image format. I expect some > churn with those over the next few months. > > So hopefully this helps to explain what you are seeing. I think folks > might be interested in see j2re-image vs. jre and j2sdk-image vs. jdk > sizes too. > > -Alan. From xerxes at zafena.se Wed Dec 3 13:37:46 2014 From: xerxes at zafena.se (=?windows-1252?Q?Xerxes_R=E5nby?=) Date: Wed, 03 Dec 2014 14:37:46 +0100 Subject: RFR [JEP 220] Modular Run-Time Images - fix zero build In-Reply-To: References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> Message-ID: <547F122A.2000705@zafena.se> Hi Chris! The build changes introduced a new dependency that sa-jdi.jar is always built. The sa-jdi.jar do not get built for Zero and Itanium builds. Zero is built using the --with-jvm-interpreter=cpp --with-jvm-variants=zero configure options. The sa-jdi.jar also do not exist if you use the --with-import-hotspot= to import alternative OpenJDK JVM such as a pre-compiled CACAO JVM or JamVM libjvm.so . I would suggest to change the jdk/make/Import.gmk and jdk/make/gensrc/Gensrc-jdk.jdi.gmk to first check if sa-jdi.jar exist before adding it to the SA_TARGETS and GENSRC_JDK_JDI something like this: Index: openjdk-jdk9-b38/jdk/make/Import.gmk =================================================================== --- openjdk-jdk9-b38.orig/jdk/make/Import.gmk 2014-11-17 17:34:13.830175424 +0100 +++ openjdk-jdk9-b38/jdk/make/Import.gmk 2014-11-18 09:10:25.420715300 +0100 @@ -221,6 +221,8 @@ # even if zip is already unpacked. $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services: $(HOTSPOT_DIST)/lib/sa-jdi.jar +# sa-jdi.jar do not exist for Itanium and zero +if [ -a $(HOTSPOT_DIST)/lib/sa-jdi.jar ] ; \ SA_TARGETS += $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \ $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services Index: openjdk-jdk9-b38/jdk/make/gensrc/Gensrc-jdk.jdi.gmk =================================================================== --- openjdk-jdk9-b38.orig/jdk/make/gensrc/Gensrc-jdk.jdi.gmk 2014-11-18 08:57:26.504852865 +0100 +++ openjdk-jdk9-b38/jdk/make/gensrc/Gensrc-jdk.jdi.gmk 2014-11-18 09:10:43.348804201 +0100 @@ -78,12 +78,10 @@ $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector $(install-file) +# sa-jdi.jar do not exist for Itanium and zero +if [ -a $(HOTSPOT_DIST)/lib/sa-jdi.jar ] ; \ GENSRC_JDK_JDI += $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector \ $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/META-INF/services/com.sun.jdi.connect.Connector Cheers Xerxes >> From: Chris Hegarty >> Subject: RFR [JEP 220] Modular Run-Time Images >> Date: 20 November 2014 21:39:14 GMT >> To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons , Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie , Mandy Chung , Mark Reinhold , Paul Sandoz , "A. Sundararajan" >> >> This is a review request for the changes for JEP 220: Modular Run-Time Images [1]. >> >> There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the 'To' section of this mail, and they will help address any comments arising from this review request. >> >> The new run-time image structure is defined in JEP 220 [1], and can be seen as a result of building the staging forest [2], or in the early access builds [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8061971/00/ >> >> Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev. >> >> -Chris. >> >> [1] http://openjdk.java.net/jeps/220 >> [2] http://hg.openjdk.java.net/jigsaw/m2/ >> [3] http://openjdk.java.net/projects/jigsaw/ea From Alan.Bateman at oracle.com Thu Dec 4 17:11:19 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Dec 2014 17:11:19 +0000 Subject: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint In-Reply-To: <54808E18.4070403@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <54805A8E.4030806@zafena.se> <54806647.5050300@oracle.com> <54808E18.4070403@oracle.com> Message-ID: <548095B7.2020809@oracle.com> On 04/12/2014 16:38, Naoto Sato wrote: > Quick question. Why is jdk.localedata module included in the compact > profiles? The data there used to be in lib/ext/localedata.jar and > lib/ext/cldrdata.jar which weren't included in those compact profiles. > > Naoto The "profiles" make target on JDK 8 (and JDK 9 before yesterday) always included localedata.jar in the images. I would expect this would be pruned or removed before deploying to an embedded device of course, same thing for the security providers that get included by default. We've now moved to world where the runtime images are created from a set of modules and this should give a lot of flexibility once. We're just not there yet with locale data so we have to temporarily link in the big jdk.localedata module so that the profiles images have all locales. -Alan. From volker.simonis at gmail.com Thu Dec 4 17:49:57 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Dec 2014 18:49:57 +0100 Subject: RFR(XS): 8066589: Make importing sa-jdi.jar optional on its existance Message-ID: Hi, could you please review this tiny change which fixes the build on platforms which don't built the SA agent after the recent modualrity integrations: http://cr.openjdk.java.net/~simonis/webrevs/8066589 https://bugs.openjdk.java.net/browse/JDK-8066589 I've tested that the fix works on AIX but I havn't had a chance to build Zero. @Xerxes: maybe you could check if my suggested fix also solves your build problems. I'm also no sure if the "ifneq ($(JVM_VARIANT_ZERO), true)" clause also catches the ZEROSHARK case (altough I think it should). If not we would need yet another "ifneq ($(JVM_VARIANT_ZEROSHARK), true)" Thanks, Volker From staffan.friberg at oracle.com Thu Dec 4 17:51:33 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Thu, 04 Dec 2014 09:51:33 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547EECE4.9030809@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> <547E39B2.4050108@oracle.com> <547E3CCF.8040009@oracle.com> <547E3FCE.2010001@oracle.com> <547EECE4.9030809@oracle.com> Message-ID: <54809F25.90702@oracle.com> On 12/03/2014 02:58 AM, Magnus Ihse Bursie wrote: > On 2014-12-02 23:45, Christian Thalinger wrote: >>> On Dec 2, 2014, at 2:40 PM, Jonathan Gibbons >>> wrote: >>> >>> Staffan, >>> >>> That seems to put it on the low end for reasonably being its own >>> repo, if you wanted that, at least, as indicated by the numbers. >> Do we really want more repositories? > As long as the number of repositories are around a dozen, one more or > less does not really matter. But our model will probably not scale > well with hundreds of repos (e.g. if someone would suggest that every > module should reside in a separate repo). > > My suggestion is that the microbenchmarks are put in the top-level > repo, if only for the reason that it seems fully possible to split > them out to a separate repo some time in the future if it grows too > much, but it seems much more unlikely that it will ever be moved back > into the top-level repo if we realized it was a stupid idea to put it > in a separate repo. > > /Magnus I like this idea, and agree that shifting in the opposite direction is probably something that would be much more work than breaking it out if size becomes an issue further down the road. When moving a directory to a new sub-repository, is there any concern about the diffs for that set of files still lingering in the top repo, or can those be moved as well? Thanks, Staffan From chris.plummer at oracle.com Thu Dec 4 20:37:17 2014 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 04 Dec 2014 12:37:17 -0800 Subject: [9] RFR (XS) 8066507: JPRT is not capable of running jtreg tests located jdk/test Message-ID: <5480C5FD.80004@oracle.com> Please review the following fix to allow running jdk jtreg tests using JPRT -rtests. This is the same fix that his been in place in hotspot/test/Makefile for a while now, so I just copied from there to jdk/test/Makefile. https://bugs.openjdk.java.net/browse/JDK-8066507 http://cr.openjdk.java.net/~cjplummer/8066507/webrev.00/ thanks, Chris From chris.plummer at oracle.com Thu Dec 4 20:37:21 2014 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 04 Dec 2014 12:37:21 -0800 Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when run using JPRT Message-ID: <5480C601.9040701@oracle.com> Please review the following fix to address JPRT timeout issues when using -rtests to run hotspot JTReg tests on slow devices. The same logic has been in place for jdk/test/Makefile for a while now, so I just copied from there to hotspot/test/Makefile. https://bugs.openjdk.java.net/browse/JDK-8066508 http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/ thanks, Chris From tim.bell at oracle.com Thu Dec 4 20:58:13 2014 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 04 Dec 2014 12:58:13 -0800 Subject: [9] RFR (XS) 8066507: JPRT is not capable of running jtreg tests located jdk/test In-Reply-To: <5480C5FD.80004@oracle.com> References: <5480C5FD.80004@oracle.com> Message-ID: <5480CAE5.6070509@oracle.com> Hi Chris: > Please review the following fix to allow running jdk jtreg tests using > JPRT -rtests. This is the same fix that his been in place in > hotspot/test/Makefile for a while now, so I just copied from there to > jdk/test/Makefile. > > https://bugs.openjdk.java.net/browse/JDK-8066507 > http://cr.openjdk.java.net/~cjplummer/8066507/webrev.00/ Looks good to me. Tim From david.holmes at oracle.com Thu Dec 4 23:27:36 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Dec 2014 09:27:36 +1000 Subject: [8u60] RFR: 8038189: Add cross-platform compact profiles support In-Reply-To: <54802108.5030300@oracle.com> References: <547BB1C4.1000303@oracle.com> <547C3296.8000000@oracle.com> <547D3F09.5010308@oracle.com> <547FD20E.9020604@oracle.com> <54802108.5030300@oracle.com> Message-ID: <5480EDE8.6030605@oracle.com> Thanks Erik. Once 8u/dev is open for 8u60 I'll request push approval. David On 4/12/2014 6:53 PM, Erik Joelsson wrote: > Looks good to me. > > /Erik > > On 2014-12-04 04:16, David Holmes wrote: >> Updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk.v2/ >> >> Only changes are to profile-includes.txt. >> >> Thanks, >> David >> >> On 2/12/2014 2:24 PM, David Holmes wrote: >>> Erik, >>> >>> Many thanks for the makefile macro wizardry! I will incorporate, test >>> and return with an updated webreb. >>> >>> David >>> >>> On 1/12/2014 7:19 PM, Erik Joelsson wrote: >>>> Hello David, >>>> >>>> Most of it looks good, but profile-includes.txt could certainly benefit >>>> from some reduction in duplication. (Aside from the extension of the >>>> file itself, which I find a bit weird, but it's already there.) The two >>>> common structures that I can see are: >>>> 1. Expanding debuginfo files for macosx. >>>> 2. Assigning/expanding libraries to the correct variable. >>>> >>>> For macosx debuginfo expanding, I would define a macro to something >>>> like >>>> this: >>>> >>>> # Expand the contents of the .dSYM directories on macosx. >>>> # Param 1 - debug files list >>>> # Param 2 - libraries list >>>> define expand-debuginfo >>>> $(if $(and $(filter-out true, $(ZIP_DEBUGINFO_FILES)), $(filter >>>> macosx, $(OPENJDK_TARGET_OS))), \ >>>> $(foreach i, $1, $(addsuffix /Contents/Info.plist, $i)) \ >>>> $(foreach i, $2, $(addsuffix /Contents/Resources/DWARF/$i, >>>> $(filter $i.%, $1))), \ >>>> $1) >>>> endef >>>> >>>> And use it like this: >>>> >>>> PROFILE_1_DEBUG_FILES := $(call expand-debuginfo, >>>> $(PROFILE_1_DEBUG_FILES), $(PROFILE_1_LIBRARIES)) >>>> >>>> Filtering out jsig can be done on the parameters at the macro call. >>>> >>>> For the conditional addprefix of OPENJDK_TARGET_CPU_LEGACY_LIB, I would >>>> do something like: >>>> >>>> ifeq (, $(findstring $(OPENJDK_TARGET_OS), windows macosx)) >>>> LIB_SUBDIR := $(OPENJDK_TARGET_CPU_LEGACY_LIB)/ >>>> else >>>> LIB_SUBDIR := >>>> endif >>>> >>>> And then always assign PROFILE_*_JRE_LIB_FILES with $(addprefix >>>> $(LIB_SUBDIR), ...). The conditional on Windows for assigning to >>>> ...BIN_FILES or ...LIB_FILES I would leave in place since I don't think >>>> a macro solution would make it easier to understand. >>>> >>>> /Erik >>>> >>>> >>>> On 2014-12-01 01:09, David Holmes wrote: >>>>> Main bug is 8038189 but that is a closed bug, the open backport issue >>>>> is: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8066200 >>>>> >>>>> Compact Profiles support was added in 8, but only for the Linux >>>>> platform. I've now generalized this support to all the other >>>>> platforms. This is an 8u only change, targetting 8u60, as soon as the >>>>> jdk8u/dev starts accepting things for 8u60. >>>>> >>>>> The changes are not that extensive - mostly generalizing the lists and >>>>> accounting for different platforms putting files into different places >>>>> (jre/lib/ vs jre/lib vs jre/bin). It isn't necessary to produce >>>>> detailed per-platform lists as files that don't exist simply don't get >>>>> copied; but when files are obviously platform specific then I add them >>>>> under suitable guards. >>>>> >>>>> The biggest complexity comes from the debuginfo files, and in >>>>> particular unzipped debuginfo files. This accounts for the bulk of the >>>>> changes in profiles-includes.txt, as we try to identify the set of >>>>> debug files that might exist for each library (and OSX is the main >>>>> complication due to the .dSYM directory because the existing rules >>>>> only copy files not directories). Suggestions for reducing the >>>>> duplicated patterns would be appreciated. >>>>> >>>>> Platform specific contents were determined in conjunction with >>>>> examination of what Jigsaw is using in JDK 9 for the base module. >>>>> >>>>> I tested all the main platforms (Windows, Linux, Solaris and OSX) and >>>>> with/without zipping of debuginfo files. Note that Windows builds will >>>>> not work with unzipped debuginfo files due to 8025936, but I checked >>>>> that multiple debug info files were expanded into the right set of >>>>> targets. >>>>> >>>>> webrevs: >>>>> >>>>> http://cr.openjdk.java.net/~dholmes/8038189/webrev.top/ >>>>> >>>>> make/Main.gmk: >>>>> - Remove the os-check that constrained profiles to linux >>>>> >>>>> http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk/ >>>>> >>>>> make/CreateJars.gmk: >>>>> - Check for empty variables (Solaris doesn't like them) >>>>> - Fix # # comments >>>>> - Add explicit targets for the beanless classes with $ in them (the % >>>>> substitution doesn't work on all platforms when $ is also present) >>>>> >>>>> make/Images.gmk >>>>> - Don't filter out server VM from compact profiles >>>>> >>>>> make/Import.gmk >>>>> - Add Info.plist to the exported files (for unzipped debuginfo files >>>>> - this is a general fix not profiles specific so may warrant its >>>>> own CR) >>>>> >>>>> make/Profiles.gmk >>>>> - Remove linux-only comment >>>>> >>>>> make/Tools.gmk >>>>> - Fix tool definitions to use $(PATH_SEP) and quote cp entries >>>>> >>>>> make/profile-includes.txt >>>>> - Bulk of changes as described above >>>>> >>>>> make/profile-rtjar-includes.txt >>>>> - Additional packages that exist on OSX only (but don't need to be >>>>> conditionally added) >>>>> - NOTE: if AIX or other platform add platform specific packages not >>>>> already included by an enclosing package, then they will also need to >>>>> be added >>>>> >>>>> Thanks, >>>>> David >>>> > From david.holmes at oracle.com Thu Dec 4 23:48:24 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Dec 2014 09:48:24 +1000 Subject: [9] RFR (XS) 8066507: JPRT is not capable of running jtreg tests located jdk/test In-Reply-To: <5480C5FD.80004@oracle.com> References: <5480C5FD.80004@oracle.com> Message-ID: <5480F2C8.4020601@oracle.com> Looks good! Thanks for fixing. David On 5/12/2014 6:37 AM, Chris Plummer wrote: > Please review the following fix to allow running jdk jtreg tests using > JPRT -rtests. This is the same fix that his been in place in > hotspot/test/Makefile for a while now, so I just copied from there to > jdk/test/Makefile. > > https://bugs.openjdk.java.net/browse/JDK-8066507 > http://cr.openjdk.java.net/~cjplummer/8066507/webrev.00/ > > thanks, > > Chris From david.holmes at oracle.com Thu Dec 4 23:52:02 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Dec 2014 09:52:02 +1000 Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when run using JPRT In-Reply-To: <5480C601.9040701@oracle.com> References: <5480C601.9040701@oracle.com> Message-ID: <5480F3A2.9070600@oracle.com> Hi Chris, Sorry I mis-directed you to send this one to build-dev, as it is a hotspot test/Makefile fix it should be reviewed by hotspot-dev now cc'd. Fix looks good to me. Thanks, David On 5/12/2014 6:37 AM, Chris Plummer wrote: > Please review the following fix to address JPRT timeout issues when > using -rtests to run hotspot JTReg tests on slow devices. The same logic > has been in place for jdk/test/Makefile for a while now, so I just > copied from there to hotspot/test/Makefile. > > https://bugs.openjdk.java.net/browse/JDK-8066508 > http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/ > > thanks, > > Chris > From mark.reinhold at oracle.com Fri Dec 5 00:11:47 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 04 Dec 2014 16:11:47 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <54809F25.90702@oracle.com> References: <547D02E5.8070507@oracle.com>, <547DD133.1050706@oracle.com>, <547E18BE.2070201@oracle.com>, <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com>, <547E3854.3060705@oracle.com>, <547E39B2.4050108@oracle.com>, <547E3CCF.8040009@oracle.com>, <547E3FCE.2010001@oracle.com>, , <547EECE4.9030809@oracle.com>, <54809F25.90702@oracle.com> Message-ID: <20141204161147.170828@eggemoggin.niobe.net> 2014/12/4 9:51 -0800, staffan.friberg at oracle.com: > On 12/03/2014 02:58 AM, Magnus Ihse Bursie wrote: >> ... >> >> My suggestion is that the microbenchmarks are put in the top-level >> repo, if only for the reason that it seems fully possible to split >> them out to a separate repo some time in the future if it grows too >> much, but it seems much more unlikely that it will ever be moved back >> into the top-level repo if we realized it was a stupid idea to put it >> in a separate repo. > > I like this idea, and agree that shifting in the opposite direction is > probably something that would be much more work than breaking it out if > size becomes an issue further down the road. > > When moving a directory to a new sub-repository, is there any concern > about the diffs for that set of files still lingering in the top repo, > or can those be moved as well? The files can be moved, but their earlier history will remain in the top-level repo. Given the forest structure that we have today, and the fact that this set of tests could grow to a thousand or so files over time, I think it makes more sense to place them in a new top-level repo of their own. In the (very?) long term we might dramatically reduce the number of repositories but that will be a huge change, and in the mean time adding one more repo is a pretty minor change and also consistent with current practice. A pleasant property of the current root repo is that it's very small (< 9MB) and easy to understand, containing mostly makefiles, build utilities, and some metadata. Placing tests in it would start turning it into more of a grab-bag. I don't think it makes sense to split the microbenchmarks across different repos, as we already do with the unit and regression tests. The latter types of tests primarily address the correctness of the code in one repo, on the assumption that any code in other repos upon which that code depends is correct. In most cases, therefore, it's pretty easy to tell whether a unit or regression test is specific to, say, the jdk repo, the langtools repo, or some other repo. Microbenchmarks, by contrast, address the performance of a particular API, language construct, or other programmatic interface and also all of the code upon which it depends, regardless of which repo it came from. By nature they're more holistic, and so less strongly associated with the code in any particular repo. - Mark From david.holmes at oracle.com Fri Dec 5 00:34:01 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Dec 2014 10:34:01 +1000 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547D02E5.8070507@oracle.com> References: <547D02E5.8070507@oracle.com> Message-ID: <5480FD79.2050802@oracle.com> Hi Staffan, On 2/12/2014 10:08 AM, Staffan Friberg wrote: > Hi, > > Hopefully this is the right list for this discussion. > > As part of adding Microbenchmarks to the OpenJDK source tree, I'm trying > to understand how we best would add the benchmark sources to the > existing OpenJDK tree structure. Is there a reason this needs to be inside the OpenJDK instead of a stand-alone project? If it ends up in its own repo and the repo is not needed by anything else, then it is already like a stand-alone project. David > Since the microbenchmark suite will cover all parts of the JDK, covering > HotSpot, JDK libraries and Nashorn, it would be preferred to add the > microbenchmark directory as a new top level directory. Something similar > to the following structure. Having "benchmark" as the top-level > directory would allow us to later add different types of benchmarks > without colliding with the microbenchmark suite. > > / > benchmark/microbenchmark/... > hotspot/... > jdk/... > nashorn/... > > With this as the premise I can see the following 3 options for how this > could be added to the source code layout > > 1. Part of jdk-root repository > * Only makes sense if we want to move in a direction with fewer > trees (and eventually a single tree) > 2. Part of another already existing tree > * Not sure if this is possible without converting and moving the > directory to a subdirectory of that tree > 3. New tree in the forest/tree structure > * Most logical option as it follows the current setup and structure > > > Anyone have any comments and/or concerns on the suggested directory > location and the tree structure in option 3. > > Would the build-dev team be the right group to later help setup a new > tree if decided to be the right way to go? > > Regards, > Staffan > From david.holmes at oracle.com Fri Dec 5 00:41:51 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Dec 2014 10:41:51 +1000 Subject: Confirming JDK 8 GA version In-Reply-To: <54802053.4030206@oracle.com> References: <923F21021934C74299CD42CCCD265DA117068B34@USINDEM101.corp.hds.com> <547E9BFB.10205@oracle.com>, <547ECADE.4020506@oracle.com> <923F21021934C74299CD42CCCD265DA117069CCD@USINDEM101.corp.hds.com> <54802053.4030206@oracle.com> Message-ID: <5480FF4F.4070601@oracle.com> Just to further clarify things, the hotspot version is set in the build files: jdk8/hotspot/make/hotspot_version HS_MAJOR_VER=25 HS_MINOR_VER=0 HS_BUILD_NUMBER=70 so that is why you see it in your local build. The JDK version string, as Erik says, takes on values based on configure arguments (if passed) else defaults (that can include timestamps). The official Oracle JDK builds use a specific format for the JDK version string. Also if you look in hotspot/.hgtags you will see the last two lines: 9f9179e8f0cfe74c08f3716cf3c38e21e1de4c4a hs25-b70 0c94c41dcd70e9a9b4d96e31275afd5a73daa72d jdk8-b132 confirming that JDK8-b132 corresponds to hotspot hs25-b70. David On 4/12/2014 6:50 PM, Erik Joelsson wrote: > > On 2014-12-03 21:54, Medi Montaseri wrote: >> Thanks David and Erik, >> >> A bit more confused...I don't know what hotspot is. > Hotspot is the jvm, basically libjvm.so (and a few of the support libs) > and has historically been treated as a separate project from the rest of > the jdk. Because of that it has its own version string. When you run > java -version in jdk8, you see three lines. The last one that says "VM" > belongs to Hotspot. It ignores the input from configure. >> I am aware of configure --with-build-number and --with-milestone and >> indeed use them....and that is why I get >> >> bin/java -version >> openjdk version "1.8.0-20141202" // note how this version >> is stamped with a date >> OpenJDK Runtime Environment (build 1.8.0-20141202-HDS-174701) >> // note how this portion is also decorated with date, label and more >> numbers >> OpenJDK 64-Bit Server VM (build 25.0-b70, mixed mode) >> ^^^^ /// >> what is this b70 >> >> The b70 makes me think that I am not working with the tip > Look at that line with "VM" and "b70" and compare it to the same line > from jdk8 GA. They are the exact same. >> Let me ask the question another way... >> >> If I pull the latest and "hg tags" says b132 as in >> >>>> unix> cd srcDir/jdk ; hg tags | head -2 >>>> tip 9107:687fd7c7986d >>>> jdk8-b132 9106:43cb25339b55 >>>> >> Can I then be sure that I am indeed working with the tip...? > AFAIK yes. >> >> David...you see how yours is showing the b132 >> >>> java version "1.8.0" >>> Java(TM) SE Runtime Environment (build 1.8.0-b132) // look >>> there is the b132 thing -b132 >>> Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode) > Yes, this shows b132, in the line that is only defined by configure > arguments, and that you are setting to something else. > > /Erik >> Again, I need to make sure I have the latest and be able to query some >> binary (java or javac) to show that it is the latest. >> >> Thanks >> Medi >> >> ________________________________________ >> From: Erik Joelsson [erik.joelsson at oracle.com] >> Sent: Wednesday, December 03, 2014 12:33 AM >> To: David Holmes; Medi Montaseri; build-dev at openjdk.java.net >> Subject: Re: Confirming JDK 8 GA version >> >> The source/makefiles are not aware of the build number. It's assigned >> from an external source at the time of building a promoted build. If you >> want your version number to better match 8 GA, you will have to play >> around with the configure arguments --with-build-number and possibly >> --with-milestone. >> >> Also, as David pointed out, in JDK 8, hotspot has it's own numbering. >> >> /Erik >> >> On 2014-12-03 06:13, David Holmes wrote: >>> On 3/12/2014 12:25 PM, Medi Montaseri wrote: >>>> Hi, >>>> >>>> Just wanted to confirm some issues: >>>> I am interested in building the latest (tip) of jdk8 GA release. >>>> >>>> 1- jdk8 GA is different from jdk8u (u is for updates), I should get >>>> the src from http://hg.openjdk.java.net/jdk8/jdk8 >>>> 2- The latest tagged version of the src is >>>> "jdk8-b132 9106:43cb25339b55" >>>> 3- I confirm that I have the latest src (for GA) by running "hg tags" >>>> like >>>> unix> cd srcDir/jdk ; hg tags | head -2 >>>> tip 9107:687fd7c7986d >>>> jdk8-b132 9106:43cb25339b55 >>>> >>>> I go ahead and build everything and then run "java -version" and I see >>>> >>>> openjdk version "1.8.0-20141202" >>>> OpenJDK Runtime Environment (build 1.8.0-20141202-HDS-174701) >>>> OpenJDK 64-Bit Server VM (build 25.0-b70, mixed mode) >>>> >>>> Q- Why am I seeing "build 25.0-b70" ? Does this "b70" has anything to >>>> do with above "jdk8-b132" ? >>> That is the hotspot version number and build number as used in the GA >>> build of JDK 8. It is correct. >>> >>> java version "1.8.0" >>> Java(TM) SE Runtime Environment (build 1.8.0-b132) >>> Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode) >>> >>> David >>> ----- >>> >>>> Thanks >>>> Medi >>>> > From medi.montaseri at hds.com Fri Dec 5 00:57:06 2014 From: medi.montaseri at hds.com (Medi Montaseri) Date: Fri, 5 Dec 2014 00:57:06 +0000 Subject: Confirming JDK 8 GA version In-Reply-To: <5480FF4F.4070601@oracle.com> References: <923F21021934C74299CD42CCCD265DA117068B34@USINDEM101.corp.hds.com> <547E9BFB.10205@oracle.com>,<547ECADE.4020506@oracle.com> <923F21021934C74299CD42CCCD265DA117069CCD@USINDEM101.corp.hds.com> <54802053.4030206@oracle.com> <5480FF4F.4070601@oracle.com> Message-ID: <548102E1.1000006@hds.com> Thank you very much David and Erik for clarifying these issues for me. Looks like we all believe it doing it right, doing it once. I am impressed. Good job Medi On 12/04/2014 04:41 PM, David Holmes wrote: Just to further clarify things, the hotspot version is set in the build files: jdk8/hotspot/make/hotspot_version HS_MAJOR_VER=25 HS_MINOR_VER=0 HS_BUILD_NUMBER=70 so that is why you see it in your local build. The JDK version string, as Erik says, takes on values based on configure arguments (if passed) else defaults (that can include timestamps). The official Oracle JDK builds use a specific format for the JDK version string. Also if you look in hotspot/.hgtags you will see the last two lines: 9f9179e8f0cfe74c08f3716cf3c38e21e1de4c4a hs25-b70 0c94c41dcd70e9a9b4d96e31275afd5a73daa72d jdk8-b132 confirming that JDK8-b132 corresponds to hotspot hs25-b70. David On 4/12/2014 6:50 PM, Erik Joelsson wrote: On 2014-12-03 21:54, Medi Montaseri wrote: Thanks David and Erik, A bit more confused...I don't know what hotspot is. Hotspot is the jvm, basically libjvm.so (and a few of the support libs) and has historically been treated as a separate project from the rest of the jdk. Because of that it has its own version string. When you run java -version in jdk8, you see three lines. The last one that says "VM" belongs to Hotspot. It ignores the input from configure. I am aware of configure --with-build-number and --with-milestone and indeed use them....and that is why I get bin/java -version openjdk version "1.8.0-20141202" // note how this version is stamped with a date OpenJDK Runtime Environment (build 1.8.0-20141202-HDS-174701) // note how this portion is also decorated with date, label and more numbers OpenJDK 64-Bit Server VM (build 25.0-b70, mixed mode) ^^^^ /// what is this b70 The b70 makes me think that I am not working with the tip Look at that line with "VM" and "b70" and compare it to the same line from jdk8 GA. They are the exact same. Let me ask the question another way... If I pull the latest and "hg tags" says b132 as in unix> cd srcDir/jdk ; hg tags | head -2 tip 9107:687fd7c7986d jdk8-b132 9106:43cb25339b55 Can I then be sure that I am indeed working with the tip...? AFAIK yes. David...you see how yours is showing the b132 java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) // look there is the b132 thing -b132 Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode) Yes, this shows b132, in the line that is only defined by configure arguments, and that you are setting to something else. /Erik Again, I need to make sure I have the latest and be able to query some binary (java or javac) to show that it is the latest. Thanks Medi ________________________________________ From: Erik Joelsson [erik.joelsson at oracle.com] Sent: Wednesday, December 03, 2014 12:33 AM To: David Holmes; Medi Montaseri; build-dev at openjdk.java.net Subject: Re: Confirming JDK 8 GA version The source/makefiles are not aware of the build number. It's assigned from an external source at the time of building a promoted build. If you want your version number to better match 8 GA, you will have to play around with the configure arguments --with-build-number and possibly --with-milestone. Also, as David pointed out, in JDK 8, hotspot has it's own numbering. /Erik On 2014-12-03 06:13, David Holmes wrote: On 3/12/2014 12:25 PM, Medi Montaseri wrote: Hi, Just wanted to confirm some issues: I am interested in building the latest (tip) of jdk8 GA release. 1- jdk8 GA is different from jdk8u (u is for updates), I should get the src from http://hg.openjdk.java.net/jdk8/jdk8 2- The latest tagged version of the src is "jdk8-b132 9106:43cb25339b55" 3- I confirm that I have the latest src (for GA) by running "hg tags" like unix> cd srcDir/jdk ; hg tags | head -2 tip 9107:687fd7c7986d jdk8-b132 9106:43cb25339b55 I go ahead and build everything and then run "java -version" and I see openjdk version "1.8.0-20141202" OpenJDK Runtime Environment (build 1.8.0-20141202-HDS-174701) OpenJDK 64-Bit Server VM (build 25.0-b70, mixed mode) Q- Why am I seeing "build 25.0-b70" ? Does this "b70" has anything to do with above "jdk8-b132" ? That is the hotspot version number and build number as used in the GA build of JDK 8. It is correct. java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode) David ----- Thanks Medi From joe.darcy at oracle.com Fri Dec 5 06:23:22 2014 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 04 Dec 2014 22:23:22 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <5480FD79.2050802@oracle.com> References: <547D02E5.8070507@oracle.com> <5480FD79.2050802@oracle.com> Message-ID: <54814F5A.9010009@oracle.com> Hello, On 12/4/2014 4:34 PM, David Holmes wrote: > Hi Staffan, > > On 2/12/2014 10:08 AM, Staffan Friberg wrote: >> Hi, >> >> Hopefully this is the right list for this discussion. >> >> As part of adding Microbenchmarks to the OpenJDK source tree, I'm trying >> to understand how we best would add the benchmark sources to the >> existing OpenJDK tree structure. > > Is there a reason this needs to be inside the OpenJDK instead of a > stand-alone project? If it ends up in its own repo and the repo is not > needed by anything else, then it is already like a stand-alone project. I think David is raising a good question here. A related question is if we want to update/fix the microbenchmarks, in how many release trains will we want to make that fix? If the expected answer is much greater than one, to me that would seem to me to argue for a separate forest in the overall OpenJDK effort, but not bundled into a particular release. For example, in the past, the webrev.ksh script was included in the JDK forest. That was an improvement over every engineer having his or her personal fork, but still made keeping webrev updated unnecessarily difficult since any changes would need to be done multiple time and there is nothing fundamentally binding a version of webrev to a particular JDK release. Likewise, even though (to my knowledge) jtreg is only used for testing the JDK, jtreg has its own repository and release schedule separate from any JDK release. So if the microbenchmarks are to a first-approximation version agnostic, then they should probably have a forest not associated with a JDK release. If they are tightly bound to a release, that argues for putting them into the JDK forest itself. -Joe > > David > >> Since the microbenchmark suite will cover all parts of the JDK, covering >> HotSpot, JDK libraries and Nashorn, it would be preferred to add the >> microbenchmark directory as a new top level directory. Something similar >> to the following structure. Having "benchmark" as the top-level >> directory would allow us to later add different types of benchmarks >> without colliding with the microbenchmark suite. >> >> / >> benchmark/microbenchmark/... >> hotspot/... >> jdk/... >> nashorn/... >> >> With this as the premise I can see the following 3 options for how this >> could be added to the source code layout >> >> 1. Part of jdk-root repository >> * Only makes sense if we want to move in a direction with fewer >> trees (and eventually a single tree) >> 2. Part of another already existing tree >> * Not sure if this is possible without converting and moving the >> directory to a subdirectory of that tree >> 3. New tree in the forest/tree structure >> * Most logical option as it follows the current setup and >> structure >> >> >> Anyone have any comments and/or concerns on the suggested directory >> location and the tree structure in option 3. >> >> Would the build-dev team be the right group to later help setup a new >> tree if decided to be the right way to go? >> >> Regards, >> Staffan >> From staffan.larsen at oracle.com Fri Dec 5 08:11:59 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 5 Dec 2014 09:11:59 +0100 Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when run using JPRT In-Reply-To: <5480F3A2.9070600@oracle.com> References: <5480C601.9040701@oracle.com> <5480F3A2.9070600@oracle.com> Message-ID: <65E426D6-B2A5-467B-B7B4-E436F1D5C84E@oracle.com> Running with longer timeouts on fast machines makes the testing less responsive (if a test is on its way to timeout it takes longer for us to detect it). Ideally the timeout factor should be tuned according to the machine type we are running on. I?m not sure that is possible, though? > On 5 dec 2014, at 00:52, David Holmes wrote: > > Hi Chris, > > Sorry I mis-directed you to send this one to build-dev, as it is a hotspot test/Makefile fix it should be reviewed by hotspot-dev now cc'd. > > Fix looks good to me. > > Thanks, > David > > On 5/12/2014 6:37 AM, Chris Plummer wrote: >> Please review the following fix to address JPRT timeout issues when >> using -rtests to run hotspot JTReg tests on slow devices. The same logic >> has been in place for jdk/test/Makefile for a while now, so I just >> copied from there to hotspot/test/Makefile. >> >> https://bugs.openjdk.java.net/browse/JDK-8066508 >> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/ >> >> thanks, >> >> Chris >> From erik.joelsson at oracle.com Fri Dec 5 09:11:15 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 05 Dec 2014 10:11:15 +0100 Subject: RFR(XS): 8066589: Make importing sa-jdi.jar optional on its existance In-Reply-To: References: Message-ID: <548176B3.3040707@oracle.com> Hello Volker, Are these the only conditions for when sa-jdi.jar is not built? If so, then I suppose this is fine. The old Import.gmk would only copy sa-jdi.jar if it existed, and I think we can keep that behavior, so just an existence check on sa-jdi.jar is good enough in Import.gmk. In Gensrc-jdk.jdi.gmk, checking if $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services exists should be fine with me. We lose a bit of error checking in the build doing it that way as we won't fail if that file is missing for other reasons. Note that this hacking of the service provider files is a temporary hack until service providers are properly handled in the modular world, so no need for fancy solutions. /Erik On 2014-12-04 18:49, Volker Simonis wrote: > Hi, > > could you please review this tiny change which fixes the build on > platforms which don't built the SA agent after the recent modualrity > integrations: > > http://cr.openjdk.java.net/~simonis/webrevs/8066589 > https://bugs.openjdk.java.net/browse/JDK-8066589 > > I've tested that the fix works on AIX but I havn't had a chance to build Zero. > > @Xerxes: maybe you could check if my suggested fix also solves your > build problems. I'm also no sure if the "ifneq ($(JVM_VARIANT_ZERO), > true)" clause also catches the ZEROSHARK case (altough I think it > should). If not we would need yet another "ifneq > ($(JVM_VARIANT_ZEROSHARK), true)" > > Thanks, > Volker From david.holmes at oracle.com Fri Dec 5 09:22:39 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Dec 2014 19:22:39 +1000 Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when run using JPRT In-Reply-To: <65E426D6-B2A5-467B-B7B4-E436F1D5C84E@oracle.com> References: <5480C601.9040701@oracle.com> <5480F3A2.9070600@oracle.com> <65E426D6-B2A5-467B-B7B4-E436F1D5C84E@oracle.com> Message-ID: <5481795F.4020403@oracle.com> On 5/12/2014 6:11 PM, Staffan Larsen wrote: > Running with longer timeouts on fast machines makes the testing less responsive (if a test is on its way to timeout it takes longer for us to detect it). Ideally the timeout factor should be tuned according to the machine type we are running on. I?m not sure that is possible, though? We don't have that level of control unfortunately. David >> On 5 dec 2014, at 00:52, David Holmes wrote: >> >> Hi Chris, >> >> Sorry I mis-directed you to send this one to build-dev, as it is a hotspot test/Makefile fix it should be reviewed by hotspot-dev now cc'd. >> >> Fix looks good to me. >> >> Thanks, >> David >> >> On 5/12/2014 6:37 AM, Chris Plummer wrote: >>> Please review the following fix to address JPRT timeout issues when >>> using -rtests to run hotspot JTReg tests on slow devices. The same logic >>> has been in place for jdk/test/Makefile for a while now, so I just >>> copied from there to hotspot/test/Makefile. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8066508 >>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/ >>> >>> thanks, >>> >>> Chris >>> > From staffan.larsen at oracle.com Fri Dec 5 09:33:59 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 5 Dec 2014 10:33:59 +0100 Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when run using JPRT In-Reply-To: <5481795F.4020403@oracle.com> References: <5480C601.9040701@oracle.com> <5480F3A2.9070600@oracle.com> <65E426D6-B2A5-467B-B7B4-E436F1D5C84E@oracle.com> <5481795F.4020403@oracle.com> Message-ID: <861FF0F5-C825-43C5-833E-F5C6BA2E4ACF@oracle.com> > On 5 dec 2014, at 10:22, David Holmes wrote: > > On 5/12/2014 6:11 PM, Staffan Larsen wrote: >> Running with longer timeouts on fast machines makes the testing less responsive (if a test is on its way to timeout it takes longer for us to detect it). Ideally the timeout factor should be tuned according to the machine type we are running on. I?m not sure that is possible, though? > > We don't have that level of control unfortunately. Too bad. /Staffan > > David > >>> On 5 dec 2014, at 00:52, David Holmes wrote: >>> >>> Hi Chris, >>> >>> Sorry I mis-directed you to send this one to build-dev, as it is a hotspot test/Makefile fix it should be reviewed by hotspot-dev now cc'd. >>> >>> Fix looks good to me. >>> >>> Thanks, >>> David >>> >>> On 5/12/2014 6:37 AM, Chris Plummer wrote: >>>> Please review the following fix to address JPRT timeout issues when >>>> using -rtests to run hotspot JTReg tests on slow devices. The same logic >>>> has been in place for jdk/test/Makefile for a while now, so I just >>>> copied from there to hotspot/test/Makefile. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8066508 >>>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/ >>>> >>>> thanks, >>>> >>>> Chris >>>> >> From david.holmes at oracle.com Fri Dec 5 09:45:37 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Dec 2014 19:45:37 +1000 Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when run using JPRT In-Reply-To: <5481795F.4020403@oracle.com> References: <5480C601.9040701@oracle.com> <5480F3A2.9070600@oracle.com> <65E426D6-B2A5-467B-B7B4-E436F1D5C84E@oracle.com> <5481795F.4020403@oracle.com> Message-ID: <54817EC1.4070407@oracle.com> On 5/12/2014 7:22 PM, David Holmes wrote: > On 5/12/2014 6:11 PM, Staffan Larsen wrote: >> Running with longer timeouts on fast machines makes the testing less >> responsive (if a test is on its way to timeout it takes longer for us >> to detect it). Ideally the timeout factor should be tuned according to >> the machine type we are running on. I?m not sure that is possible, >> though? > > We don't have that level of control unfortunately. Sorry that's not true. As this is our Makefile we could make the timeout value platform specific (though remember this is an open file). And if we have some means of defining a performance metric for a machine, we could even tune it for the current machine - but I'm not sure we'd want to go that path anyway. Perhaps a RFE. What Chris is proposing addresses a current problem and brings hotspot testing into line with what the JDK testing has been doing since 2009. :) David > David > >>> On 5 dec 2014, at 00:52, David Holmes wrote: >>> >>> Hi Chris, >>> >>> Sorry I mis-directed you to send this one to build-dev, as it is a >>> hotspot test/Makefile fix it should be reviewed by hotspot-dev now cc'd. >>> >>> Fix looks good to me. >>> >>> Thanks, >>> David >>> >>> On 5/12/2014 6:37 AM, Chris Plummer wrote: >>>> Please review the following fix to address JPRT timeout issues when >>>> using -rtests to run hotspot JTReg tests on slow devices. The same >>>> logic >>>> has been in place for jdk/test/Makefile for a while now, so I just >>>> copied from there to hotspot/test/Makefile. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8066508 >>>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/ >>>> >>>> thanks, >>>> >>>> Chris >>>> >> From magnus.ihse.bursie at oracle.com Fri Dec 5 12:40:55 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 05 Dec 2014 13:40:55 +0100 Subject: RFR: JDK-8066769 Merge errors following JDK-8049367 (Modular Run-Time Images) Message-ID: <5481A7D7.3080906@oracle.com> JDK-8049367 (Modular Run-Time Images) contained large pieces of heavily changed build logic. Getting such a thing in place is not easy. A few, non-critical, merge errors crept up: * Whitespace cleanup disappaeard * Improvements in compare.sh were lost. Bug: https://bugs.openjdk.java.net/browse/JDK-8066769 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8066769-jigsaw-m2-merge-errors/webrev.01 /Magnus From erik.joelsson at oracle.com Fri Dec 5 12:47:47 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 05 Dec 2014 13:47:47 +0100 Subject: RFR: JDK-8066769 Merge errors following JDK-8049367 (Modular Run-Time Images) In-Reply-To: <5481A7D7.3080906@oracle.com> References: <5481A7D7.3080906@oracle.com> Message-ID: <5481A973.8080302@oracle.com> Looks good to me. /Erik On 2014-12-05 13:40, Magnus Ihse Bursie wrote: > JDK-8049367 (Modular Run-Time Images) contained large pieces of > heavily changed build logic. Getting such a thing in place is not easy. > > A few, non-critical, merge errors crept up: > * Whitespace cleanup disappaeard > * Improvements in compare.sh were lost. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066769 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8066769-jigsaw-m2-merge-errors/webrev.01 > > /Magnus From daniel.daugherty at oracle.com Fri Dec 5 14:05:18 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 05 Dec 2014 07:05:18 -0700 Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when run using JPRT In-Reply-To: <54817EC1.4070407@oracle.com> References: <5480C601.9040701@oracle.com> <5480F3A2.9070600@oracle.com> <65E426D6-B2A5-467B-B7B4-E436F1D5C84E@oracle.com> <5481795F.4020403@oracle.com> <54817EC1.4070407@oracle.com> Message-ID: <5481BB9E.5040906@oracle.com> On 12/5/14 2:45 AM, David Holmes wrote: > On 5/12/2014 7:22 PM, David Holmes wrote: >> On 5/12/2014 6:11 PM, Staffan Larsen wrote: >>> Running with longer timeouts on fast machines makes the testing less >>> responsive (if a test is on its way to timeout it takes longer for us >>> to detect it). Ideally the timeout factor should be tuned according to >>> the machine type we are running on. I?m not sure that is possible, >>> though? >> >> We don't have that level of control unfortunately. > > Sorry that's not true. As this is our Makefile we could make the > timeout value platform specific (though remember this is an open > file). And if we have some means of defining a performance metric for > a machine, we could even tune it for the current machine - but I'm not > sure we'd want to go that path anyway. Perhaps a RFE. > > What Chris is proposing addresses a current problem and brings hotspot > testing into line with what the JDK testing has been doing since 2009. :) I'm fairly certain that VM/SQE nightly tunes the JavaTest/JTREG timeout factor depending on the machine type or the machine name itself; I don't know the exact details. I suspect that this is possible in VM/SQE nightly/Aurora because there is a database of per-machine info. It might be possible to do something similar for JPRT if it tracks information per client machine... Dan > > David > >> David >> >>>> On 5 dec 2014, at 00:52, David Holmes wrote: >>>> >>>> Hi Chris, >>>> >>>> Sorry I mis-directed you to send this one to build-dev, as it is a >>>> hotspot test/Makefile fix it should be reviewed by hotspot-dev now >>>> cc'd. >>>> >>>> Fix looks good to me. >>>> >>>> Thanks, >>>> David >>>> >>>> On 5/12/2014 6:37 AM, Chris Plummer wrote: >>>>> Please review the following fix to address JPRT timeout issues when >>>>> using -rtests to run hotspot JTReg tests on slow devices. The same >>>>> logic >>>>> has been in place for jdk/test/Makefile for a while now, so I just >>>>> copied from there to hotspot/test/Makefile. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8066508 >>>>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/ >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>> > > > From volker.simonis at gmail.com Fri Dec 5 14:07:22 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 5 Dec 2014 15:07:22 +0100 Subject: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only Message-ID: Hi, after the integration of the modular changes into jdk9-dev the executable commands in jdk/bin and jre/bin images are only executable by the file owner. This means that only the user who built the images can execute the programs. This can be easily fixed with the following trivial change: http://cr.openjdk.java.net/~simonis/webrevs/8066766/ https://bugs.openjdk.java.net/browse/JDK-8066766 Thanks, Volker From chris.hegarty at oracle.com Fri Dec 5 14:18:06 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 05 Dec 2014 14:18:06 +0000 Subject: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only In-Reply-To: References: Message-ID: <5481BE9E.7020904@oracle.com> Thanks Volker, I agree with your change, or you can take the code from ImageBuilder. Either is fine with me. private void setExecutable(Path file) { try { Set perms = Files.getPosixFilePermissions(file); perms.add(PosixFilePermission.OWNER_EXECUTE); perms.add(PosixFilePermission.GROUP_EXECUTE); perms.add(PosixFilePermission.OTHERS_EXECUTE); Files.setPosixFilePermissions(file, perms); } catch (IOException ioe) { throw new UncheckedIOException(ioe); } } -Chris. On 05/12/14 14:07, Volker Simonis wrote: > Hi, > > after the integration of the modular changes into jdk9-dev the > executable commands in jdk/bin and jre/bin images are only executable > by the file owner. This means that only the user who built the images > can execute the programs. > > This can be easily fixed with the following trivial change: > > http://cr.openjdk.java.net/~simonis/webrevs/8066766/ > https://bugs.openjdk.java.net/browse/JDK-8066766 > > Thanks, > Volker > From magnus.ihse.bursie at oracle.com Fri Dec 5 14:47:01 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 05 Dec 2014 15:47:01 +0100 Subject: RFR: JDK-8065576: Enable pipefail in the shell used by make to better detect build errors In-Reply-To: <547C6CAE.40600@oracle.com> References: <5475EA0E.6040405@oracle.com> <54766066.9060206@oracle.com> <547C6CAE.40600@oracle.com> Message-ID: <5481C565.4080204@oracle.com> On 2014-12-01 14:27, Erik Joelsson wrote: > Hello, > > New webrev, which addresses Magnus' concern below, and various fixes > in Hotspot for incompatibilities with errexit. > > Webrev: http://cr.openjdk.java.net/~erikj/8065576/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8065576 > > For the LOG=trace issue Magnus described below, it was enough to just > replace $$(BASH) with $$(SHELL) and things worked as expected for me. I'm a bit surprised at this. Did the options really fall through into the actual shell executing in the wrapper? But if you say it reall works, I'm fine with it. The rest of the code looks good. /Magnus From volker.simonis at gmail.com Fri Dec 5 16:50:59 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 5 Dec 2014 17:50:59 +0100 Subject: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only In-Reply-To: <5481BE9E.7020904@oracle.com> References: <5481BE9E.7020904@oracle.com> Message-ID: Hi Chris, thanks for the fast response. I saw that code in ImageBuilder, but it looked overly complicated to me. What about cleaning that up as well: http://cr.openjdk.java.net/~simonis/webrevs/8066766.v2/ I've just checked that on Solaris 'jspawnhelper' still has the right execution bits set after the change. Regards, Volker On Fri, Dec 5, 2014 at 3:18 PM, Chris Hegarty wrote: > Thanks Volker, > > I agree with your change, or you can take the code from ImageBuilder. Either > is fine with me. > > private void setExecutable(Path file) { > try { > Set perms = > Files.getPosixFilePermissions(file); > perms.add(PosixFilePermission.OWNER_EXECUTE); > perms.add(PosixFilePermission.GROUP_EXECUTE); > perms.add(PosixFilePermission.OTHERS_EXECUTE); > Files.setPosixFilePermissions(file, perms); > } catch (IOException ioe) { > throw new UncheckedIOException(ioe); > } > } > > -Chris. > > > On 05/12/14 14:07, Volker Simonis wrote: >> >> Hi, >> >> after the integration of the modular changes into jdk9-dev the >> executable commands in jdk/bin and jre/bin images are only executable >> by the file owner. This means that only the user who built the images >> can execute the programs. >> >> This can be easily fixed with the following trivial change: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8066766/ >> https://bugs.openjdk.java.net/browse/JDK-8066766 >> >> Thanks, >> Volker >> > From Alan.Bateman at oracle.com Fri Dec 5 17:00:11 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 05 Dec 2014 17:00:11 +0000 Subject: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only In-Reply-To: References: <5481BE9E.7020904@oracle.com> Message-ID: <5481E49B.3050908@oracle.com> On 05/12/2014 16:50, Volker Simonis wrote: > Hi Chris, > > thanks for the fast response. > > I saw that code in ImageBuilder, but it looked overly complicated to > me. What about cleaning that up as well: > > http://cr.openjdk.java.net/~simonis/webrevs/8066766.v2/ > > I've just checked that on Solaris 'jspawnhelper' still has the right > execution bits set after the change. setExecutable doesn't throw an exception when it fails so this is why it's not used here. It's probably not a big deal here of course, esp. as this is just a temporary tool for the build that we hope to replace soon. -Alan From volker.simonis at gmail.com Fri Dec 5 17:26:36 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 5 Dec 2014 18:26:36 +0100 Subject: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only In-Reply-To: <5481E49B.3050908@oracle.com> References: <5481BE9E.7020904@oracle.com> <5481E49B.3050908@oracle.com> Message-ID: On Fri, Dec 5, 2014 at 6:00 PM, Alan Bateman wrote: > On 05/12/2014 16:50, Volker Simonis wrote: >> >> Hi Chris, >> >> thanks for the fast response. >> >> I saw that code in ImageBuilder, but it looked overly complicated to >> me. What about cleaning that up as well: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8066766.v2/ >> >> I've just checked that on Solaris 'jspawnhelper' still has the right >> execution bits set after the change. > > setExecutable doesn't throw an exception when it fails so this is why it's > not used here. > But why do we need an exception if setting the executable flags fails on 'jspawnhelper' and don't need on if it fails on the executables. We'll actually never notice that 'jspawnhelper' isn't executable if we can't execute 'java', right? Moreover the old solution depends on the fact that PosixFilePermission are available. I understand that the 'jspawnhelper' is probably only used on systems which run on a posix files system, but who knows. On the other side using setExecutable() on all executables as proposed by Chris seems dangarous, because Windows probably doesn't supports PosixFilePermission so we will always get exceptions. > It's probably not a big deal here of course, esp. as this is just a > temporary tool for the build that we hope to replace soon. > So do you agree with the clean-up in my second webrev or should I just change the way how the executables are treated (like in my first webrev)? Thank you and best regards, Volker > -Alan From Alan.Bateman at oracle.com Fri Dec 5 17:34:22 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 05 Dec 2014 17:34:22 +0000 Subject: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only In-Reply-To: References: <5481BE9E.7020904@oracle.com> <5481E49B.3050908@oracle.com> Message-ID: <5481EC9E.8050904@oracle.com> On 05/12/2014 17:26, Volker Simonis wrote: > But why do we need an exception if setting the executable flags fails > on 'jspawnhelper' and don't need on if it fails on the executables. > We'll actually never notice that 'jspawnhelper' isn't executable if we > can't execute 'java', right? > It is consistent, we should fix that. -Alan. From Alan.Bateman at oracle.com Fri Dec 5 17:37:38 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 05 Dec 2014 17:37:38 +0000 Subject: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only In-Reply-To: <5481EC9E.8050904@oracle.com> References: <5481BE9E.7020904@oracle.com> <5481E49B.3050908@oracle.com> <5481EC9E.8050904@oracle.com> Message-ID: <5481ED62.3070302@oracle.com> On 05/12/2014 17:34, Alan Bateman wrote: > On 05/12/2014 17:26, Volker Simonis wrote: >> But why do we need an exception if setting the executable flags fails >> on 'jspawnhelper' and don't need on if it fails on the executables. >> We'll actually never notice that 'jspawnhelper' isn't executable if we >> can't execute 'java', right? >> > It is consistent, we should fix that. s/consistent/inconsistent/ From volker.simonis at gmail.com Fri Dec 5 17:49:12 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 5 Dec 2014 18:49:12 +0100 Subject: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only In-Reply-To: <5481ED62.3070302@oracle.com> References: <5481BE9E.7020904@oracle.com> <5481E49B.3050908@oracle.com> <5481EC9E.8050904@oracle.com> <5481ED62.3070302@oracle.com> Message-ID: On Fri, Dec 5, 2014 at 6:37 PM, Alan Bateman wrote: > On 05/12/2014 17:34, Alan Bateman wrote: >> >> On 05/12/2014 17:26, Volker Simonis wrote: >>> >>> But why do we need an exception if setting the executable flags fails >>> on 'jspawnhelper' and don't need on if it fails on the executables. >>> We'll actually never notice that 'jspawnhelper' isn't executable if we >>> can't execute 'java', right? >>> >> It is consistent, we should fix that. > > > s/consistent/inconsistent/ Agree, but which way round? Is it OK to use File.setExecutable() on all executables or should I use ImageBuilder.setExecutable() which has the problem of throwing an exception on non-posix file systems? From Sergey.Bylokhov at oracle.com Fri Dec 5 17:57:14 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 05 Dec 2014 20:57:14 +0300 Subject: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint In-Reply-To: <548095B7.2020809@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <54805A8E.4030806@zafena.se> <54806647.5050300@oracle.com> <54808E18.4070403@oracle.com> <548095B7.2020809@oracle.com> Message-ID: <5481F1FA.6050500@oracle.com> On 04.12.2014 20:11, Alan Bateman wrote: > We've now moved to world where the runtime images are created from a > set of modules and this should give a lot of flexibility once. We're > just not there yet with locale data so we have to temporarily link in > the big jdk.localedata module so that the profiles images have all > locales. Just curious, how will we track the size of modules? Probably we can save this information during the build time, so regressions will be found easily? > > -Alan. -- Best regards, Sergey. From chris.hegarty at oracle.com Fri Dec 5 18:09:01 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 5 Dec 2014 18:09:01 +0000 Subject: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only In-Reply-To: References: <5481BE9E.7020904@oracle.com> Message-ID: Volker, Personally I would use the more verbose version, Files.setPosixFilePermissions, so we can see any failures. But as Alan pointed out, this is a temporary build tool, and I live with it either way. Is there any reason why you cannot use the NIO API ? -Chris. On 5 Dec 2014, at 16:50, Volker Simonis wrote: > Hi Chris, > > thanks for the fast response. > > I saw that code in ImageBuilder, but it looked overly complicated to > me. What about cleaning that up as well: > > http://cr.openjdk.java.net/~simonis/webrevs/8066766.v2/ > > I've just checked that on Solaris 'jspawnhelper' still has the right > execution bits set after the change. > > Regards, > Volker > > On Fri, Dec 5, 2014 at 3:18 PM, Chris Hegarty wrote: >> Thanks Volker, >> >> I agree with your change, or you can take the code from ImageBuilder. Either >> is fine with me. >> >> private void setExecutable(Path file) { >> try { >> Set perms = >> Files.getPosixFilePermissions(file); >> perms.add(PosixFilePermission.OWNER_EXECUTE); >> perms.add(PosixFilePermission.GROUP_EXECUTE); >> perms.add(PosixFilePermission.OTHERS_EXECUTE); >> Files.setPosixFilePermissions(file, perms); >> } catch (IOException ioe) { >> throw new UncheckedIOException(ioe); >> } >> } >> >> -Chris. >> >> >> On 05/12/14 14:07, Volker Simonis wrote: >>> >>> Hi, >>> >>> after the integration of the modular changes into jdk9-dev the >>> executable commands in jdk/bin and jre/bin images are only executable >>> by the file owner. This means that only the user who built the images >>> can execute the programs. >>> >>> This can be easily fixed with the following trivial change: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8066766/ >>> https://bugs.openjdk.java.net/browse/JDK-8066766 >>> >>> Thanks, >>> Volker >>> >> From volker.simonis at gmail.com Fri Dec 5 18:14:26 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 5 Dec 2014 19:14:26 +0100 Subject: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only In-Reply-To: References: <5481BE9E.7020904@oracle.com> Message-ID: On Fri, Dec 5, 2014 at 7:09 PM, Chris Hegarty wrote: > Volker, > > Personally I would use the more verbose version, Files.setPosixFilePermissions, so we can see any failures. But as Alan pointed out, this is a temporary build tool, and I live with it either way. Is there any reason why you cannot use the NIO API ? No, for me it's no problem. I was just wondering if Files.setPosixFilePermissions() would work on Windows. Because now it is only used for the 'jspawnhelper' which is not built on Windows. If Files.setPosixFilePermissions() doesn't throw an exception on Windows I'll be happy to use that version for the binaries as well. > > -Chris. > > On 5 Dec 2014, at 16:50, Volker Simonis wrote: > >> Hi Chris, >> >> thanks for the fast response. >> >> I saw that code in ImageBuilder, but it looked overly complicated to >> me. What about cleaning that up as well: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8066766.v2/ >> >> I've just checked that on Solaris 'jspawnhelper' still has the right >> execution bits set after the change. >> >> Regards, >> Volker >> >> On Fri, Dec 5, 2014 at 3:18 PM, Chris Hegarty wrote: >>> Thanks Volker, >>> >>> I agree with your change, or you can take the code from ImageBuilder. Either >>> is fine with me. >>> >>> private void setExecutable(Path file) { >>> try { >>> Set perms = >>> Files.getPosixFilePermissions(file); >>> perms.add(PosixFilePermission.OWNER_EXECUTE); >>> perms.add(PosixFilePermission.GROUP_EXECUTE); >>> perms.add(PosixFilePermission.OTHERS_EXECUTE); >>> Files.setPosixFilePermissions(file, perms); >>> } catch (IOException ioe) { >>> throw new UncheckedIOException(ioe); >>> } >>> } >>> >>> -Chris. >>> >>> >>> On 05/12/14 14:07, Volker Simonis wrote: >>>> >>>> Hi, >>>> >>>> after the integration of the modular changes into jdk9-dev the >>>> executable commands in jdk/bin and jre/bin images are only executable >>>> by the file owner. This means that only the user who built the images >>>> can execute the programs. >>>> >>>> This can be easily fixed with the following trivial change: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8066766/ >>>> https://bugs.openjdk.java.net/browse/JDK-8066766 >>>> >>>> Thanks, >>>> Volker >>>> >>> > From chris.hegarty at oracle.com Fri Dec 5 18:43:03 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 5 Dec 2014 18:43:03 +0000 Subject: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only In-Reply-To: References: <5481BE9E.7020904@oracle.com> Message-ID: <9456CE58-6F49-4FED-BB71-BB2AC9A40125@oracle.com> On 5 Dec 2014, at 18:14, Volker Simonis wrote: > On Fri, Dec 5, 2014 at 7:09 PM, Chris Hegarty wrote: >> Volker, >> >> Personally I would use the more verbose version, Files.setPosixFilePermissions, so we can see any failures. But as Alan pointed out, this is a temporary build tool, and I live with it either way. Is there any reason why you cannot use the NIO API ? > > No, for me it's no problem. I was just wondering if > Files.setPosixFilePermissions() would work on Windows. Because now it > is only used for the 'jspawnhelper' which is not built on Windows. If > Files.setPosixFilePermissions() doesn't throw an exception on Windows > I'll be happy to use that version for the binaries as well. OK thanks. You are saving us from ourselves! Please go with your 2nd webrev. http://cr.openjdk.java.net/~simonis/webrevs/8066766.v2/ -Chris. >> -Chris. >> >> On 5 Dec 2014, at 16:50, Volker Simonis wrote: >> >>> Hi Chris, >>> >>> thanks for the fast response. >>> >>> I saw that code in ImageBuilder, but it looked overly complicated to >>> me. What about cleaning that up as well: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8066766.v2/ >>> >>> I've just checked that on Solaris 'jspawnhelper' still has the right >>> execution bits set after the change. >>> >>> Regards, >>> Volker >>> >>> On Fri, Dec 5, 2014 at 3:18 PM, Chris Hegarty wrote: >>>> Thanks Volker, >>>> >>>> I agree with your change, or you can take the code from ImageBuilder. Either >>>> is fine with me. >>>> >>>> private void setExecutable(Path file) { >>>> try { >>>> Set perms = >>>> Files.getPosixFilePermissions(file); >>>> perms.add(PosixFilePermission.OWNER_EXECUTE); >>>> perms.add(PosixFilePermission.GROUP_EXECUTE); >>>> perms.add(PosixFilePermission.OTHERS_EXECUTE); >>>> Files.setPosixFilePermissions(file, perms); >>>> } catch (IOException ioe) { >>>> throw new UncheckedIOException(ioe); >>>> } >>>> } >>>> >>>> -Chris. >>>> >>>> >>>> On 05/12/14 14:07, Volker Simonis wrote: >>>>> >>>>> Hi, >>>>> >>>>> after the integration of the modular changes into jdk9-dev the >>>>> executable commands in jdk/bin and jre/bin images are only executable >>>>> by the file owner. This means that only the user who built the images >>>>> can execute the programs. >>>>> >>>>> This can be easily fixed with the following trivial change: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8066766/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8066766 >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>> >> From volker.simonis at gmail.com Fri Dec 5 18:50:40 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 5 Dec 2014 19:50:40 +0100 Subject: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only In-Reply-To: <9456CE58-6F49-4FED-BB71-BB2AC9A40125@oracle.com> References: <5481BE9E.7020904@oracle.com> <9456CE58-6F49-4FED-BB71-BB2AC9A40125@oracle.com> Message-ID: On Fri, Dec 5, 2014 at 7:43 PM, Chris Hegarty wrote: > On 5 Dec 2014, at 18:14, Volker Simonis wrote: > >> On Fri, Dec 5, 2014 at 7:09 PM, Chris Hegarty wrote: >>> Volker, >>> >>> Personally I would use the more verbose version, Files.setPosixFilePermissions, so we can see any failures. But as Alan pointed out, this is a temporary build tool, and I live with it either way. Is there any reason why you cannot use the NIO API ? >> >> No, for me it's no problem. I was just wondering if >> Files.setPosixFilePermissions() would work on Windows. Because now it >> is only used for the 'jspawnhelper' which is not built on Windows. If >> Files.setPosixFilePermissions() doesn't throw an exception on Windows >> I'll be happy to use that version for the binaries as well. > > OK thanks. You are saving us from ourselves! Please go with your 2nd webrev. > http://cr.openjdk.java.net/~simonis/webrevs/8066766.v2/ > Great, thanks. Pushed to jdk9/dev. Regards, Volker > -Chris. > > >>> -Chris. >>> >>> On 5 Dec 2014, at 16:50, Volker Simonis wrote: >>> >>>> Hi Chris, >>>> >>>> thanks for the fast response. >>>> >>>> I saw that code in ImageBuilder, but it looked overly complicated to >>>> me. What about cleaning that up as well: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8066766.v2/ >>>> >>>> I've just checked that on Solaris 'jspawnhelper' still has the right >>>> execution bits set after the change. >>>> >>>> Regards, >>>> Volker >>>> >>>> On Fri, Dec 5, 2014 at 3:18 PM, Chris Hegarty wrote: >>>>> Thanks Volker, >>>>> >>>>> I agree with your change, or you can take the code from ImageBuilder. Either >>>>> is fine with me. >>>>> >>>>> private void setExecutable(Path file) { >>>>> try { >>>>> Set perms = >>>>> Files.getPosixFilePermissions(file); >>>>> perms.add(PosixFilePermission.OWNER_EXECUTE); >>>>> perms.add(PosixFilePermission.GROUP_EXECUTE); >>>>> perms.add(PosixFilePermission.OTHERS_EXECUTE); >>>>> Files.setPosixFilePermissions(file, perms); >>>>> } catch (IOException ioe) { >>>>> throw new UncheckedIOException(ioe); >>>>> } >>>>> } >>>>> >>>>> -Chris. >>>>> >>>>> >>>>> On 05/12/14 14:07, Volker Simonis wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> after the integration of the modular changes into jdk9-dev the >>>>>> executable commands in jdk/bin and jre/bin images are only executable >>>>>> by the file owner. This means that only the user who built the images >>>>>> can execute the programs. >>>>>> >>>>>> This can be easily fixed with the following trivial change: >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8066766/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8066766 >>>>>> >>>>>> Thanks, >>>>>> Volker >>>>>> >>>>> >>> > From medi.montaseri at hds.com Fri Dec 5 19:36:28 2014 From: medi.montaseri at hds.com (Medi Montaseri) Date: Fri, 5 Dec 2014 19:36:28 +0000 Subject: How to get notified of latest GA Release Message-ID: <5482093B.6070202@hds.com> Hi, We would like to stay on the heels of OpenJDK GA Releases. Such as current jdk8u20 and later jdk8u40. Is there any recommendation on how to go about it? Options that I can think of include: 1- A SOAP API portal would be nice, but I don't think it exists today. 2- How about mercurial itself? But I think I need some consistent tagging and the format of it. So far I know it looks like jdk8u20-bnn. 3- Parse some web page. This is least desirable. web pages are too artistic and they change every week 4- Email, same problem as web page, it restricts the publisher as well. You guys know better...so to recap....I want to run a cron and find out if there is a new GA release, and if so proceed with fetch and build. Thanks Medi From staffan.friberg at oracle.com Fri Dec 5 19:46:38 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Fri, 05 Dec 2014 11:46:38 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <54814F5A.9010009@oracle.com> References: <547D02E5.8070507@oracle.com> <5480FD79.2050802@oracle.com> <54814F5A.9010009@oracle.com> Message-ID: <54820B9E.3080209@oracle.com> Hi, On 12/04/2014 10:23 PM, joe darcy wrote: > Hello, > > On 12/4/2014 4:34 PM, David Holmes wrote: >> Hi Staffan, >> >> On 2/12/2014 10:08 AM, Staffan Friberg wrote: >>> Hi, >>> >>> Hopefully this is the right list for this discussion. >>> >>> As part of adding Microbenchmarks to the OpenJDK source tree, I'm >>> trying >>> to understand how we best would add the benchmark sources to the >>> existing OpenJDK tree structure. >> >> Is there a reason this needs to be inside the OpenJDK instead of a >> stand-alone project? If it ends up in its own repo and the repo is >> not needed by anything else, then it is already like a stand-alone >> project. > > I think David is raising a good question here. A related question is > if we want to update/fix the microbenchmarks, in how many release > trains will we want to make that fix? If the expected answer is much > greater than one, to me that would seem to me to argue for a separate > forest in the overall OpenJDK effort, but not bundled into a > particular release. > > For example, in the past, the webrev.ksh script was included in the > JDK forest. That was an improvement over every engineer having his or > her personal fork, but still made keeping webrev updated unnecessarily > difficult since any changes would need to be done multiple time and > there is nothing fundamentally binding a version of webrev to a > particular JDK release. Likewise, even though (to my knowledge) jtreg > is only used for testing the JDK, jtreg has its own repository and > release schedule separate from any JDK release. > > So if the microbenchmarks are to a first-approximation version > agnostic, then they should probably have a forest not associated with > a JDK release. If they are tightly bound to a release, that argues for > putting them into the JDK forest itself. > The reasons are similar to co-locating functional tests, stable test base that is not moving after FC, tests support new features and all work with the JDK you are developing. Looking at some of the goals in the JEP and why I think co-locating helps. * Stable and tuned benchmarks, targeted for continuous performance testing o A stable and non-moving suite after the Feature Complete milestone of a feature release, and for non-feature releases To fulfill this having a separate repository would force us to branch and create builds in sync with the JDK we want to test. As the number of JDK version increases so will the microbenchmark suite. Making it complex for anyone adding or running tests to keep track of which version one should use for a specific JDK branch. As an example, for a stable branch we probably do not want to update the JMH version, unless there is a critical bug, as doing so can invalidate any earlier results causing us to lose all history that is critical when tracking a release. However during development of a new release we probably want to do that to take advantage of new features in JMH. And we might require new features in JMH to support changes in the JDK. Fixing bugs in microbenchmarks will in a similar fashion to any bugs sometimes need to be backported, but we would have similar struggles in a separate repository if we want to keep the suite stable for multiple releases and have multiple branches to support that. JMH similar to jtreg is a separate repository already, and will stay that way. The co-located part would be the benchmarks, which similar to the tests written using jtreg benefit from being co-located. * Simplicity o Easy to add new benchmarks o Easy to update tests as APIs and options change, are deprecated, or are removed during development o Easy to find and run a benchmark Having it co-located reduces the steps for anyone developing a new feature to push benchmarks at the same time as the feature in the same way as functional tests can be pushed. Any benchmark relying on a feature being removed can easily be deleted without concern about reducing the test coverage of older releases still providing it. Having it in a completely separate repository I fear will cause microbenchmark to be out of sight and out of mind, which is the opposite of the intention of creating the suite. We want more people to write and run benchmarks in a simple way. Co-location will allow anyone to simply just add and do make to build for their current branch and test the feature they are working on, and those benchmarks will directly be picked up for regression testing once pushed. Hope this helps to further clarify the reason for having the suite as part of the OpenJDK source tree. Regards, Staffan From andreas.lundblad at oracle.com Fri Dec 5 20:08:09 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Fri, 5 Dec 2014 21:08:09 +0100 Subject: RFR: JDK-8047177: JDK build should make use of the new -XXuserPathsFirst In-Reply-To: <544F72B1.8080602@oracle.com> References: <544F72B1.8080602@oracle.com> Message-ID: <20141205200808.GF28610@e6430> On Tue, Oct 28, 2014 at 11:40:49AM +0100, Erik Joelsson wrote: > Hello, > > Please review this small fix when using sjavac. When using a bootjdk > that was built at a later date than when the source tree was > initially cloned, there is a risk that sjavac will pick up classes > from the boot classpath (rt.jar of boot jdk) instead of the source > files, concluding that the source files won't need to be built. This > is only an issue when building classes that are also present in the > boot classpath of the bootjdk, which we normally do since we are > building the jdk. > > The fix is to add a special option for this use case, which forces > sjavac to build source files if found, regardless of class file > dates. Did we get any closure on this? Background discussion on compiler-dev (subject: "timestamp oddities -sourcepath vs zip/jar") Joel, did you come to the conclusion that adding -XXuserPathsFirst would not solve our issues? (Or did I missunderstand you?) -- Andreas From chris.plummer at oracle.com Fri Dec 5 20:52:38 2014 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 05 Dec 2014 12:52:38 -0800 Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when run using JPRT In-Reply-To: <5481BB9E.5040906@oracle.com> References: <5480C601.9040701@oracle.com> <5480F3A2.9070600@oracle.com> <65E426D6-B2A5-467B-B7B4-E436F1D5C84E@oracle.com> <5481795F.4020403@oracle.com> <54817EC1.4070407@oracle.com> <5481BB9E.5040906@oracle.com> Message-ID: <54821B16.6030005@oracle.com> On 12/5/14 6:05 AM, Daniel D. Daugherty wrote: > On 12/5/14 2:45 AM, David Holmes wrote: >> On 5/12/2014 7:22 PM, David Holmes wrote: >>> On 5/12/2014 6:11 PM, Staffan Larsen wrote: >>>> Running with longer timeouts on fast machines makes the testing less >>>> responsive (if a test is on its way to timeout it takes longer for us >>>> to detect it). Ideally the timeout factor should be tuned according to >>>> the machine type we are running on. I?m not sure that is possible, >>>> though? >>> >>> We don't have that level of control unfortunately. >> >> Sorry that's not true. As this is our Makefile we could make the >> timeout value platform specific (though remember this is an open >> file). And if we have some means of defining a performance metric for >> a machine, we could even tune it for the current machine - but I'm >> not sure we'd want to go that path anyway. Perhaps a RFE. >> >> What Chris is proposing addresses a current problem and brings >> hotspot testing into line with what the JDK testing has been doing >> since 2009. :) > > I'm fairly certain that VM/SQE nightly tunes the JavaTest/JTREG > timeout factor depending on the machine type or the machine name > itself; I don't know the exact details. I suspect that this is > possible in VM/SQE nightly/Aurora because there is a database > of per-machine info. > > It might be possible to do something similar for JPRT if it > tracks information per client machine... Ok. BTW, I was not suggesting a JPRT fix instead of my above fix in the near term. I still would like to push my fix and have the timeout for hotspot/test be on par with jdk/test. I still need one more reviewer. thanks, Chris > > Dan > > >> >> David >> >>> David >>> >>>>> On 5 dec 2014, at 00:52, David Holmes >>>>> wrote: >>>>> >>>>> Hi Chris, >>>>> >>>>> Sorry I mis-directed you to send this one to build-dev, as it is a >>>>> hotspot test/Makefile fix it should be reviewed by hotspot-dev now >>>>> cc'd. >>>>> >>>>> Fix looks good to me. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 5/12/2014 6:37 AM, Chris Plummer wrote: >>>>>> Please review the following fix to address JPRT timeout issues when >>>>>> using -rtests to run hotspot JTReg tests on slow devices. The same >>>>>> logic >>>>>> has been in place for jdk/test/Makefile for a while now, so I just >>>>>> copied from there to hotspot/test/Makefile. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8066508 >>>>>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/ >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>> >> >> >> > From daniel.daugherty at oracle.com Fri Dec 5 21:48:05 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 05 Dec 2014 14:48:05 -0700 Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when run using JPRT In-Reply-To: <5480F3A2.9070600@oracle.com> References: <5480C601.9040701@oracle.com> <5480F3A2.9070600@oracle.com> Message-ID: <54822815.4000606@oracle.com> > http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/ test/Makefile No comments. Thumbs up. Please fix the Copyright year before you push. Dan On 12/4/14 4:52 PM, David Holmes wrote: > Hi Chris, > > Sorry I mis-directed you to send this one to build-dev, as it is a > hotspot test/Makefile fix it should be reviewed by hotspot-dev now cc'd. > > Fix looks good to me. > > Thanks, > David > > On 5/12/2014 6:37 AM, Chris Plummer wrote: >> Please review the following fix to address JPRT timeout issues when >> using -rtests to run hotspot JTReg tests on slow devices. The same logic >> has been in place for jdk/test/Makefile for a while now, so I just >> copied from there to hotspot/test/Makefile. >> >> https://bugs.openjdk.java.net/browse/JDK-8066508 >> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/ >> >> thanks, >> >> Chris >> > > From jonathan.gibbons at oracle.com Fri Dec 5 21:52:48 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 05 Dec 2014 13:52:48 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <54820B9E.3080209@oracle.com> References: <547D02E5.8070507@oracle.com> <5480FD79.2050802@oracle.com> <54814F5A.9010009@oracle.com> <54820B9E.3080209@oracle.com> Message-ID: <54822930.2020606@oracle.com> On 12/05/2014 11:46 AM, Staffan Friberg wrote: > Hi, > > On 12/04/2014 10:23 PM, joe darcy wrote: >> Hello, >> >> On 12/4/2014 4:34 PM, David Holmes wrote: >>> Hi Staffan, >>> >>> On 2/12/2014 10:08 AM, Staffan Friberg wrote: >>>> Hi, >>>> >>>> Hopefully this is the right list for this discussion. >>>> >>>> As part of adding Microbenchmarks to the OpenJDK source tree, I'm >>>> trying >>>> to understand how we best would add the benchmark sources to the >>>> existing OpenJDK tree structure. >>> >>> Is there a reason this needs to be inside the OpenJDK instead of a >>> stand-alone project? If it ends up in its own repo and the repo is >>> not needed by anything else, then it is already like a stand-alone >>> project. >> >> I think David is raising a good question here. A related question is >> if we want to update/fix the microbenchmarks, in how many release >> trains will we want to make that fix? If the expected answer is much >> greater than one, to me that would seem to me to argue for a separate >> forest in the overall OpenJDK effort, but not bundled into a >> particular release. >> >> For example, in the past, the webrev.ksh script was included in the >> JDK forest. That was an improvement over every engineer having his or >> her personal fork, but still made keeping webrev updated >> unnecessarily difficult since any changes would need to be done >> multiple time and there is nothing fundamentally binding a version of >> webrev to a particular JDK release. Likewise, even though (to my >> knowledge) jtreg is only used for testing the JDK, jtreg has its own >> repository and release schedule separate from any JDK release. >> >> So if the microbenchmarks are to a first-approximation version >> agnostic, then they should probably have a forest not associated with >> a JDK release. If they are tightly bound to a release, that argues >> for putting them into the JDK forest itself. >> > The reasons are similar to co-locating functional tests, stable test > base that is not moving after FC, tests support new features and all > work with the JDK you are developing. > > Looking at some of the goals in the JEP and why I think co-locating > helps. > > * Stable and tuned benchmarks, targeted for continuous performance > testing > o A stable and non-moving suite after the Feature Complete > milestone of a feature release, and for non-feature releases > > To fulfill this having a separate repository would force us to branch > and create builds in sync with the JDK we want to test. As the number > of JDK version increases so will the microbenchmark suite. Making it > complex for anyone adding or running tests to keep track of which > version one should use for a specific JDK branch. > > As an example, for a stable branch we probably do not want to update > the JMH version, unless there is a critical bug, as doing so can > invalidate any earlier results causing us to lose all history that is > critical when tracking a release. However during development of a new > release we probably want to do that to take advantage of new features > in JMH. And we might require new features in JMH to support changes in > the JDK. > > Fixing bugs in microbenchmarks will in a similar fashion to any bugs > sometimes need to be backported, but we would have similar struggles > in a separate repository if we want to keep the suite stable for > multiple releases and have multiple branches to support that. > > JMH similar to jtreg is a separate repository already, and will stay > that way. The co-located part would be the benchmarks, which similar > to the tests written using jtreg benefit from being co-located. > > > * Simplicity > o Easy to add new benchmarks > o Easy to update tests as APIs and options change, are deprecated, > or are removed during development > o Easy to find and run a benchmark > > Having it co-located reduces the steps for anyone developing a new > feature to push benchmarks at the same time as the feature in the same > way as functional tests can be pushed. > > Any benchmark relying on a feature being removed can easily be deleted > without concern about reducing the test coverage of older releases > still providing it. > > Having it in a completely separate repository I fear will cause > microbenchmark to be out of sight and out of mind, which is the > opposite of the intention of creating the suite. We want more people > to write and run benchmarks in a simple way. Co-location will allow > anyone to simply just add and do make to build for their current > branch and test the feature they are working on, and those benchmarks > will directly be picked up for regression testing once pushed. > > > > Hope this helps to further clarify the reason for having the suite as > part of the OpenJDK source tree. > > Regards, > Staffan Staffan, You make a good point for it being within the OpenJDK source tree. But you can still use a separate repository in the forest, so that it is versioned, tracked, copied along with the other trees in the forest. -- Jon From staffan.friberg at oracle.com Fri Dec 5 22:11:14 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Fri, 05 Dec 2014 14:11:14 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <54822930.2020606@oracle.com> References: <547D02E5.8070507@oracle.com> <5480FD79.2050802@oracle.com> <54814F5A.9010009@oracle.com> <54820B9E.3080209@oracle.com> <54822930.2020606@oracle.com> Message-ID: <54822D82.50409@oracle.com> Hi Jon, On 12/05/2014 01:52 PM, Jonathan Gibbons wrote: > > On 12/05/2014 11:46 AM, Staffan Friberg wrote: >> Hi, >> >> On 12/04/2014 10:23 PM, joe darcy wrote: >>> Hello, >>> >>> On 12/4/2014 4:34 PM, David Holmes wrote: >>>> Hi Staffan, >>>> >>>> On 2/12/2014 10:08 AM, Staffan Friberg wrote: >>>>> Hi, >>>>> >>>>> Hopefully this is the right list for this discussion. >>>>> >>>>> As part of adding Microbenchmarks to the OpenJDK source tree, I'm >>>>> trying >>>>> to understand how we best would add the benchmark sources to the >>>>> existing OpenJDK tree structure. >>>> >>>> Is there a reason this needs to be inside the OpenJDK instead of a >>>> stand-alone project? If it ends up in its own repo and the repo is >>>> not needed by anything else, then it is already like a stand-alone >>>> project. >>> >>> I think David is raising a good question here. A related question is >>> if we want to update/fix the microbenchmarks, in how many release >>> trains will we want to make that fix? If the expected answer is much >>> greater than one, to me that would seem to me to argue for a >>> separate forest in the overall OpenJDK effort, but not bundled into >>> a particular release. >>> >>> For example, in the past, the webrev.ksh script was included in the >>> JDK forest. That was an improvement over every engineer having his >>> or her personal fork, but still made keeping webrev updated >>> unnecessarily difficult since any changes would need to be done >>> multiple time and there is nothing fundamentally binding a version >>> of webrev to a particular JDK release. Likewise, even though (to my >>> knowledge) jtreg is only used for testing the JDK, jtreg has its own >>> repository and release schedule separate from any JDK release. >>> >>> So if the microbenchmarks are to a first-approximation version >>> agnostic, then they should probably have a forest not associated >>> with a JDK release. If they are tightly bound to a release, that >>> argues for putting them into the JDK forest itself. >>> >> The reasons are similar to co-locating functional tests, stable test >> base that is not moving after FC, tests support new features and all >> work with the JDK you are developing. >> >> Looking at some of the goals in the JEP and why I think co-locating >> helps. >> >> * Stable and tuned benchmarks, targeted for continuous performance >> testing >> o A stable and non-moving suite after the Feature Complete >> milestone of a feature release, and for non-feature releases >> >> To fulfill this having a separate repository would force us to branch >> and create builds in sync with the JDK we want to test. As the number >> of JDK version increases so will the microbenchmark suite. Making it >> complex for anyone adding or running tests to keep track of which >> version one should use for a specific JDK branch. >> >> As an example, for a stable branch we probably do not want to update >> the JMH version, unless there is a critical bug, as doing so can >> invalidate any earlier results causing us to lose all history that is >> critical when tracking a release. However during development of a new >> release we probably want to do that to take advantage of new features >> in JMH. And we might require new features in JMH to support changes >> in the JDK. >> >> Fixing bugs in microbenchmarks will in a similar fashion to any bugs >> sometimes need to be backported, but we would have similar struggles >> in a separate repository if we want to keep the suite stable for >> multiple releases and have multiple branches to support that. >> >> JMH similar to jtreg is a separate repository already, and will stay >> that way. The co-located part would be the benchmarks, which similar >> to the tests written using jtreg benefit from being co-located. >> >> >> * Simplicity >> o Easy to add new benchmarks >> o Easy to update tests as APIs and options change, are deprecated, >> or are removed during development >> o Easy to find and run a benchmark >> >> Having it co-located reduces the steps for anyone developing a new >> feature to push benchmarks at the same time as the feature in the >> same way as functional tests can be pushed. >> >> Any benchmark relying on a feature being removed can easily be >> deleted without concern about reducing the test coverage of older >> releases still providing it. >> >> Having it in a completely separate repository I fear will cause >> microbenchmark to be out of sight and out of mind, which is the >> opposite of the intention of creating the suite. We want more people >> to write and run benchmarks in a simple way. Co-location will allow >> anyone to simply just add and do make to build for their current >> branch and test the feature they are working on, and those benchmarks >> will directly be picked up for regression testing once pushed. >> >> >> >> Hope this helps to further clarify the reason for having the suite as >> part of the OpenJDK source tree. >> >> Regards, >> Staffan > > Staffan, > > You make a good point for it being within the OpenJDK source tree. But > you can still use a separate repository in the forest, so that it is > versioned, tracked, copied along with the other trees in the forest. > > -- Jon Agree, and I believe we have reached that conclusion as the best option in the "other part" of the thread. I liked the idea of starting of in the top repository as Magnus suggested, and move out if required, but as Mark confirmed the historic diffs would still be around and keeping the top repository focused on Makefiles and other meta data I think make sense as well. Regards, Staffan From chris.plummer at oracle.com Fri Dec 5 22:17:19 2014 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 05 Dec 2014 14:17:19 -0800 Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when run using JPRT In-Reply-To: <54822815.4000606@oracle.com> References: <5480C601.9040701@oracle.com> <5480F3A2.9070600@oracle.com> <54822815.4000606@oracle.com> Message-ID: <54822EEF.5080504@oracle.com> Is the copyright rule/policy to leave the oldest date and update the most recent date to the current year? Chris On 12/5/14 1:48 PM, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/ > > test/Makefile > No comments. > > Thumbs up. Please fix the Copyright year before you push. > > Dan > > > On 12/4/14 4:52 PM, David Holmes wrote: >> Hi Chris, >> >> Sorry I mis-directed you to send this one to build-dev, as it is a >> hotspot test/Makefile fix it should be reviewed by hotspot-dev now cc'd. >> >> Fix looks good to me. >> >> Thanks, >> David >> >> On 5/12/2014 6:37 AM, Chris Plummer wrote: >>> Please review the following fix to address JPRT timeout issues when >>> using -rtests to run hotspot JTReg tests on slow devices. The same >>> logic >>> has been in place for jdk/test/Makefile for a while now, so I just >>> copied from there to hotspot/test/Makefile. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8066508 >>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/ >>> >>> thanks, >>> >>> Chris >>> >> >> > From daniel.daugherty at oracle.com Fri Dec 5 22:52:31 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 05 Dec 2014 15:52:31 -0700 Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when run using JPRT In-Reply-To: <54822EEF.5080504@oracle.com> References: <5480C601.9040701@oracle.com> <5480F3A2.9070600@oracle.com> <54822815.4000606@oracle.com> <54822EEF.5080504@oracle.com> Message-ID: <5482372F.5070201@oracle.com> Yes. So '2013' -> '2014'. Dan On 12/5/14 3:17 PM, Chris Plummer wrote: > Is the copyright rule/policy to leave the oldest date and update the > most recent date to the current year? > > Chris > > On 12/5/14 1:48 PM, Daniel D. Daugherty wrote: >> > http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/ >> >> test/Makefile >> No comments. >> >> Thumbs up. Please fix the Copyright year before you push. >> >> Dan >> >> >> On 12/4/14 4:52 PM, David Holmes wrote: >>> Hi Chris, >>> >>> Sorry I mis-directed you to send this one to build-dev, as it is a >>> hotspot test/Makefile fix it should be reviewed by hotspot-dev now >>> cc'd. >>> >>> Fix looks good to me. >>> >>> Thanks, >>> David >>> >>> On 5/12/2014 6:37 AM, Chris Plummer wrote: >>>> Please review the following fix to address JPRT timeout issues when >>>> using -rtests to run hotspot JTReg tests on slow devices. The same >>>> logic >>>> has been in place for jdk/test/Makefile for a while now, so I just >>>> copied from there to hotspot/test/Makefile. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8066508 >>>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/ >>>> >>>> thanks, >>>> >>>> Chris >>>> >>> >>> >> > From Alan.Bateman at oracle.com Sat Dec 6 11:28:07 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 06 Dec 2014 11:28:07 +0000 Subject: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint In-Reply-To: <5481F1FA.6050500@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <54805A8E.4030806@zafena.se> <54806647.5050300@oracle.com> <54808E18.4070403@oracle.com> <548095B7.2020809@oracle.com> <5481F1FA.6050500@oracle.com> Message-ID: <5482E847.1030103@oracle.com> On 05/12/2014 17:57, Sergey Bylokhov wrote: > On 04.12.2014 20:11, Alan Bateman wrote: >> We've now moved to world where the runtime images are created from a >> set of modules and this should give a lot of flexibility once. We're >> just not there yet with locale data so we have to temporarily link in >> the big jdk.localedata module so that the profiles images have all >> locales. > Just curious, how will we track the size of modules? Probably we can > save this information during the build time, so regressions will be > found easily? Once we are a bit further then I expect we will generate a directory of modules, format TBD. This will be important to have when creating images outside of the JDK build environment, say a custom image with your application, some libraries and their transitive dependences. That might be the time to track the size, although it would really be just an indication, it may be very different when linked in to the eventual image (due to compression and other transformations that might happen at link time). -Alan From stuart.marks at oracle.com Sat Dec 6 21:03:13 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Sat, 06 Dec 2014 13:03:13 -0800 Subject: Modular Run-Time Images build fails with JDK8u25 as bootstrap JDK In-Reply-To: <548356EB.7000601@gmail.com> References: <548356EB.7000601@gmail.com> Message-ID: <54836F11.4020501@oracle.com> [Adding build-dev to let them know others are seeing this. I'm not on jigsaw-dev though so this might not make it there.] Hi Peter, I ran into this myself the other day and had a wrestling match with it. There's a bug in the build system on this: https://bugs.openjdk.java.net/browse/JDK-8066761 My understanding is that this has to do with timestamps on the checked-out source files vs. the class files in the boot JDK. With 8u20 as boot, all the class files are out of date w.r.t. the source files so everything is rebuilt. With 8u25, some class files might be newer than the source files, if you've been using the same source tree for a long time (as many of us have). The workaround is to touch all the source files in the jdk repo before doing a clean build: $ cd jdk; hg manifest | xargs touch or do $ cd jdk; hg update null; hg update tip to re-checkout all the files. The root cause seems to be inadvertent dependency checks against classes in the boot JDK, which cause the build to mix in old class files from the boot JDK. Obviously if you do a fresh build, everything ought to be out of date, regardless of which boot JDK is in use. s'marks On 12/6/14 11:20 AM, Peter Levart wrote: > Hi, > > I thought I might inform you that recent checkout of JDK9 (with modular RT > images) fails to build with JDK8u25 as bootstrap JDK. With JDK8u20 it works > correctly. Tried on Linux and Windows. The configuration on Linux is: > > Configuration summary: > * Debug level: release > * HS debug level: product > * JDK variant: normal > * JVM variants: server > * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64 > > Tools summary: > * Boot JDK: java version "1.8.0_25" Java(TM) SE Runtime Environment > (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed > mode) (at /home/peter/Apps64/jdk1.8.0) > * Toolchain: gcc (GNU Compiler Collection) > * C Compiler: Version 4.8.3 (at /usr/bin/gcc) > * C++ Compiler: Version 4.8.3 (at /usr/bin/g++) > > Build performance summary: > * Cores to use: 7 > * Memory limit: 15757 MB > > > Here's the build session: > > [peter at cube jdk9-dev]$ make CONF=linux-x86_64-normal-server-release images > Building 'linux-x86_64-normal-server-release' (matching > CONF=linux-x86_64-normal-server-release) > Building OpenJDK for target 'images' in configuration > 'linux-x86_64-normal-server-release' > > Compiling 1 files for BUILD_TOOLS_LANGTOOLS > Compiling 20 properties into resource bundles for jdk.compiler > Compiling 10 properties into resource bundles for jdk.javadoc > Compiling 5 properties into resource bundles for jdk.dev > Compiling 818 files for BUILD_INTERIM_LANGTOOLS > warning: [options] bootstrap class path not set in conjunction with -source 1.6 > warning: [options] bootstrap class path not set in conjunction with -source 1.6 > 1 warning > 1 warning > 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 > Warning: generation and use of skeletons and static stubs for JRMP > is deprecated. Skeletons are unnecessary, and static stubs have > been superseded by dynamically generated stubs. Users are > encouraged to migrate away from using rmic to generate skeletons and static > stubs. See the documentation for java.rmi.server.UnicastRemoteObject. > Creating buildtools/interim_langtools.jar > Compiling 198 files for BUILD_INTERIM_RMIC > Compiling 23 files for BUILD_INTERIM_JIMAGE > Compiling 6 files for BUILD_TOOLS_CORBA > Compiling 141 files for BUILD_IDLJ > /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:230: > error: cannot find symbol > LambdaForm form2 = mh.editor().filterArgumentForm(1+i, > BasicType.basicType(newType)); > ^ > symbol: method editor() > location: variable mh of type BoundMethodHandle > /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:231: > error: cannot find symbol > mh = mh.copyWithExtendL(midType, form2, fn); > ^ > symbol: method copyWithExtendL(MethodType,LambdaForm,MethodHandle) > location: variable mh of type BoundMethodHandle > /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:250: > error: cannot find symbol > LambdaForm form2 = > mh.editor().filterReturnForm(BasicType.basicType(newType), false); > ^ > symbol: method editor() > location: variable mh of type BoundMethodHandle > > ...etc... > > > It seems that something changed between JDK8u20 and JDK8u25 regarding > bootclasspath handling of javac as the above errors suggest that JDK9 sources > are being compiled against JDK8 classes. > > > Regards, Peter > > From philip.race at oracle.com Sat Dec 6 21:22:56 2014 From: philip.race at oracle.com (Phil Race) Date: Sat, 06 Dec 2014 13:22:56 -0800 Subject: Modular Run-Time Images build fails with JDK8u25 as bootstrap JDK In-Reply-To: <54836F11.4020501@oracle.com> References: <548356EB.7000601@gmail.com> <54836F11.4020501@oracle.com> Message-ID: <548373B0.90901@oracle.com> yep lots of people have reported this/seen this -phil. On 12/6/14 1:03 PM, Stuart Marks wrote: > [Adding build-dev to let them know others are seeing this. I'm not on > jigsaw-dev though so this might not make it there.] > > Hi Peter, > > I ran into this myself the other day and had a wrestling match with > it. There's a bug in the build system on this: > > https://bugs.openjdk.java.net/browse/JDK-8066761 > > My understanding is that this has to do with timestamps on the > checked-out source files vs. the class files in the boot JDK. With > 8u20 as boot, all the class files are out of date w.r.t. the source > files so everything is rebuilt. With 8u25, some class files might be > newer than the source files, if you've been using the same source tree > for a long time (as many of us have). > > The workaround is to touch all the source files in the jdk repo before > doing a clean build: > > $ cd jdk; hg manifest | xargs touch > > or do > > $ cd jdk; hg update null; hg update tip > > to re-checkout all the files. > > The root cause seems to be inadvertent dependency checks against > classes in the boot JDK, which cause the build to mix in old class > files from the boot JDK. Obviously if you do a fresh build, everything > ought to be out of date, regardless of which boot JDK is in use. > > s'marks > > On 12/6/14 11:20 AM, Peter Levart wrote: >> Hi, >> >> I thought I might inform you that recent checkout of JDK9 (with >> modular RT images) fails to build with JDK8u25 as bootstrap JDK. With >> JDK8u20 it works correctly. Tried on Linux and Windows. The >> configuration on Linux is: >> >> Configuration summary: >> * Debug level: release >> * HS debug level: product >> * JDK variant: normal >> * JVM variants: server >> * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64 >> >> Tools summary: >> * Boot JDK: java version "1.8.0_25" Java(TM) SE Runtime >> Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM >> (build 25.25-b02, mixed mode) (at /home/peter/Apps64/jdk1.8.0) >> * Toolchain: gcc (GNU Compiler Collection) >> * C Compiler: Version 4.8.3 (at /usr/bin/gcc) >> * C++ Compiler: Version 4.8.3 (at /usr/bin/g++) >> >> Build performance summary: >> * Cores to use: 7 >> * Memory limit: 15757 MB >> >> >> Here's the build session: >> >> [peter at cube jdk9-dev]$ make CONF=linux-x86_64-normal-server-release >> images >> Building 'linux-x86_64-normal-server-release' (matching >> CONF=linux-x86_64-normal-server-release) >> Building OpenJDK for target 'images' in configuration >> 'linux-x86_64-normal-server-release' >> >> Compiling 1 files for BUILD_TOOLS_LANGTOOLS >> Compiling 20 properties into resource bundles for jdk.compiler >> Compiling 10 properties into resource bundles for jdk.javadoc >> Compiling 5 properties into resource bundles for jdk.dev >> Compiling 818 files for BUILD_INTERIM_LANGTOOLS >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.6 >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.6 >> 1 warning >> 1 warning >> 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 >> Warning: generation and use of skeletons and static stubs for JRMP >> is deprecated. Skeletons are unnecessary, and static stubs have >> been superseded by dynamically generated stubs. Users are >> encouraged to migrate away from using rmic to generate skeletons and >> static >> stubs. See the documentation for java.rmi.server.UnicastRemoteObject. >> Creating buildtools/interim_langtools.jar >> Compiling 198 files for BUILD_INTERIM_RMIC >> Compiling 23 files for BUILD_INTERIM_JIMAGE >> Compiling 6 files for BUILD_TOOLS_CORBA >> Compiling 141 files for BUILD_IDLJ >> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:230: >> error: cannot find symbol >> LambdaForm form2 = mh.editor().filterArgumentForm(1+i, >> BasicType.basicType(newType)); >> ^ >> symbol: method editor() >> location: variable mh of type BoundMethodHandle >> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:231: >> error: cannot find symbol >> mh = mh.copyWithExtendL(midType, form2, fn); >> ^ >> symbol: method copyWithExtendL(MethodType,LambdaForm,MethodHandle) >> location: variable mh of type BoundMethodHandle >> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:250: >> error: cannot find symbol >> LambdaForm form2 = >> mh.editor().filterReturnForm(BasicType.basicType(newType), false); >> ^ >> symbol: method editor() >> location: variable mh of type BoundMethodHandle >> >> ...etc... >> >> >> It seems that something changed between JDK8u20 and JDK8u25 regarding >> bootclasspath handling of javac as the above errors suggest that JDK9 >> sources are being compiled against JDK8 classes. >> >> >> Regards, Peter >> >> > From peter.levart at gmail.com Sun Dec 7 00:02:30 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 07 Dec 2014 01:02:30 +0100 Subject: Modular Run-Time Images build fails with JDK8u25 as bootstrap JDK In-Reply-To: <54836F11.4020501@oracle.com> References: <548356EB.7000601@gmail.com> <54836F11.4020501@oracle.com> Message-ID: <54839916.3070306@gmail.com> Hi Stuart and Phil and Tim, Thanks for explanation. This must be it, yes. I'll try upgrading to JDK8u25 again (just downgraded to u20) and see if touching sources helps. Regards, Peter On 12/06/2014 10:03 PM, Stuart Marks wrote: > [Adding build-dev to let them know others are seeing this. I'm not on > jigsaw-dev though so this might not make it there.] > > Hi Peter, > > I ran into this myself the other day and had a wrestling match with > it. There's a bug in the build system on this: > > https://bugs.openjdk.java.net/browse/JDK-8066761 > > My understanding is that this has to do with timestamps on the > checked-out source files vs. the class files in the boot JDK. With > 8u20 as boot, all the class files are out of date w.r.t. the source > files so everything is rebuilt. With 8u25, some class files might be > newer than the source files, if you've been using the same source tree > for a long time (as many of us have). > > The workaround is to touch all the source files in the jdk repo before > doing a clean build: > > $ cd jdk; hg manifest | xargs touch > > or do > > $ cd jdk; hg update null; hg update tip > > to re-checkout all the files. > > The root cause seems to be inadvertent dependency checks against > classes in the boot JDK, which cause the build to mix in old class > files from the boot JDK. Obviously if you do a fresh build, everything > ought to be out of date, regardless of which boot JDK is in use. > > s'marks > > On 12/6/14 11:20 AM, Peter Levart wrote: >> Hi, >> >> I thought I might inform you that recent checkout of JDK9 (with >> modular RT images) fails to build with JDK8u25 as bootstrap JDK. With >> JDK8u20 it works correctly. Tried on Linux and Windows. The >> configuration on Linux is: >> >> Configuration summary: >> * Debug level: release >> * HS debug level: product >> * JDK variant: normal >> * JVM variants: server >> * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64 >> >> Tools summary: >> * Boot JDK: java version "1.8.0_25" Java(TM) SE Runtime >> Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM >> (build 25.25-b02, mixed mode) (at /home/peter/Apps64/jdk1.8.0) >> * Toolchain: gcc (GNU Compiler Collection) >> * C Compiler: Version 4.8.3 (at /usr/bin/gcc) >> * C++ Compiler: Version 4.8.3 (at /usr/bin/g++) >> >> Build performance summary: >> * Cores to use: 7 >> * Memory limit: 15757 MB >> >> >> Here's the build session: >> >> [peter at cube jdk9-dev]$ make CONF=linux-x86_64-normal-server-release >> images >> Building 'linux-x86_64-normal-server-release' (matching >> CONF=linux-x86_64-normal-server-release) >> Building OpenJDK for target 'images' in configuration >> 'linux-x86_64-normal-server-release' >> >> Compiling 1 files for BUILD_TOOLS_LANGTOOLS >> Compiling 20 properties into resource bundles for jdk.compiler >> Compiling 10 properties into resource bundles for jdk.javadoc >> Compiling 5 properties into resource bundles for jdk.dev >> Compiling 818 files for BUILD_INTERIM_LANGTOOLS >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.6 >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.6 >> 1 warning >> 1 warning >> 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 >> Warning: generation and use of skeletons and static stubs for JRMP >> is deprecated. Skeletons are unnecessary, and static stubs have >> been superseded by dynamically generated stubs. Users are >> encouraged to migrate away from using rmic to generate skeletons and >> static >> stubs. See the documentation for java.rmi.server.UnicastRemoteObject. >> Creating buildtools/interim_langtools.jar >> Compiling 198 files for BUILD_INTERIM_RMIC >> Compiling 23 files for BUILD_INTERIM_JIMAGE >> Compiling 6 files for BUILD_TOOLS_CORBA >> Compiling 141 files for BUILD_IDLJ >> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:230: >> error: cannot find symbol >> LambdaForm form2 = mh.editor().filterArgumentForm(1+i, >> BasicType.basicType(newType)); >> ^ >> symbol: method editor() >> location: variable mh of type BoundMethodHandle >> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:231: >> error: cannot find symbol >> mh = mh.copyWithExtendL(midType, form2, fn); >> ^ >> symbol: method copyWithExtendL(MethodType,LambdaForm,MethodHandle) >> location: variable mh of type BoundMethodHandle >> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:250: >> error: cannot find symbol >> LambdaForm form2 = >> mh.editor().filterReturnForm(BasicType.basicType(newType), false); >> ^ >> symbol: method editor() >> location: variable mh of type BoundMethodHandle >> >> ...etc... >> >> >> It seems that something changed between JDK8u20 and JDK8u25 regarding >> bootclasspath handling of javac as the above errors suggest that JDK9 >> sources are being compiled against JDK8 classes. >> >> >> Regards, Peter >> >> > From david.holmes at oracle.com Mon Dec 8 02:06:34 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 08 Dec 2014 12:06:34 +1000 Subject: How to get notified of latest GA Release In-Reply-To: <5482093B.6070202@hds.com> References: <5482093B.6070202@hds.com> Message-ID: <548507AA.2000703@oracle.com> On 6/12/2014 5:36 AM, Medi Montaseri wrote: > Hi, > > We would like to stay on the heels of OpenJDK GA Releases. Such as current jdk8u20 and later jdk8u40. Is there any recommendation on how to go about it? Options that I can think of include: > > 1- A SOAP API portal would be nice, but I don't think it exists today. > 2- How about mercurial itself? But I think I need some consistent tagging and the format of it. So far I know it looks like jdk8u20-bnn. > 3- Parse some web page. This is least desirable. web pages are too artistic and they change every week > 4- Email, same problem as web page, it restricts the publisher as well. > > You guys know better...so to recap....I want to run a cron and find out if there is a new GA release, and if so proceed with fetch and build. I don't think there is a way as the information as to which build becomes the GA release is not maintained within the system itself. Even internally the only way I know to find out the GA release build is to follow a "latest build" link that won't update after GA. But even then I have no way to know when that truly becomes the latest build. The only thing I can think of that confirms there is a GA release is when the forest becomes read-only, but I'm not sure how long after GA that would occur. Anyway this is not a build issue per-se so might be better raised on a more general OpenJDK list. David > Thanks > Medi > From chlict at gmail.com Mon Dec 8 09:10:38 2014 From: chlict at gmail.com (ChenLong) Date: Mon, 08 Dec 2014 17:10:38 +0800 Subject: How to cross compile OpenJDK for Arm32? Message-ID: Hi Apologize if this is not the right place to ask. I want to try OpenJDK8 on Armv7. Is there a guideline on how to cross compile OpenJDK8 for Armv7? And if not, could someone share some experiences? I went through the README-builds.html and did not find any clues for cross compiling. Thanks Chen Long From erik.joelsson at oracle.com Mon Dec 8 11:09:06 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 08 Dec 2014 12:09:06 +0100 Subject: RFR: JDK-8066828: configure fails if it's set --with-boot-jdk to use JDK 9 modular image Message-ID: <548586D2.4060602@oracle.com> Hello, Please review this fix to configure, removing the requirement that the bootjdk has an rt.jar. In the modular images change, we already did away with using the rt.jar in the boot jdk. With this fix, it becomes possible to use a modular image as boot jdk when building JDK 9. Bug: https://bugs.openjdk.java.net/browse/JDK-8066828 Webrev: http://cr.openjdk.java.net/~erikj/8066828/webrev.root.01/ /Erik From david.holmes at oracle.com Mon Dec 8 11:46:07 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 08 Dec 2014 21:46:07 +1000 Subject: How to cross compile OpenJDK for Arm32? In-Reply-To: References: Message-ID: <54858F7F.6060707@oracle.com> On 8/12/2014 7:10 PM, ChenLong wrote: > Hi > > Apologize if this is not the right place to ask. > I want to try OpenJDK8 on Armv7. Is there a guideline on how to cross compile OpenJDK8 for Armv7? And if not, could someone share some experiences? I went through the README-builds.html and did not find any clues for cross compiling. The only OpenJDK build for ARM would be a ZERO build. But I don't know how to do Zero builds - though I'm sure the Zero folk will chime in. David > Thanks > Chen Long > From erik.joelsson at oracle.com Mon Dec 8 12:09:45 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 08 Dec 2014 13:09:45 +0100 Subject: RFR: JDK-8066761: Investigate -sourcepath usage when compiling java Message-ID: <54859509.3040402@oracle.com> Hello, Please review this fix, removing the use of -sourcepath when compiling java sources. For a long time, all java compilation lines have included a -sourcepath parameter. We have now concluded that in some cases it's just wrong and the rest of the cases it's just unnecessary. I have tried building with and without this patch and enabling sjavac, and the class file output is equivalent in all cases. Bug: https://bugs.openjdk.java.net/browse/JDK-8066761 Webrev: http://cr.openjdk.java.net/~erikj/8066761/webrev.01/ /Erik From joel.franck at oracle.com Mon Dec 8 12:14:51 2014 From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=) Date: Mon, 8 Dec 2014 13:14:51 +0100 Subject: RFR: JDK-8066761: Investigate -sourcepath usage when compiling java In-Reply-To: <54859509.3040402@oracle.com> References: <54859509.3040402@oracle.com> Message-ID: <9678A25C-A377-4808-AEDE-D835029B9E2F@oracle.com> Hi Erik, Looks sane to me, but I?m not a build-dev reviewer. cheers /Joel > On 8 dec 2014, at 13:09, Erik Joelsson wrote: > > Hello, > > Please review this fix, removing the use of -sourcepath when compiling java sources. For a long time, all java compilation lines have included a -sourcepath parameter. We have now concluded that in some cases it's just wrong and the rest of the cases it's just unnecessary. > > I have tried building with and without this patch and enabling sjavac, and the class file output is equivalent in all cases. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066761 > Webrev: http://cr.openjdk.java.net/~erikj/8066761/webrev.01/ > > /Erik From erik.joelsson at oracle.com Mon Dec 8 13:53:18 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 08 Dec 2014 14:53:18 +0100 Subject: RFR: JDK-8066752: Remove space after -L on linker lines Message-ID: <5485AD4E.7020504@oracle.com> Hello, Please review this small patch, removing all instances of space following '-L' on linker lines. With certain versions of XCode on Macosx, this results in an error. Most of these instances were introduced with the modular images change. I chose to remove everything I could find, even if not used on Macosx builds, for consistency. Bug: https://bugs.openjdk.java.net/browse/JDK-8066752 Webrev: http://cr.openjdk.java.net/~erikj/8066752/webrev.jdk.01/ /Erik From Alan.Bateman at oracle.com Mon Dec 8 14:02:47 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Dec 2014 14:02:47 +0000 Subject: RFR: JDK-8066761: Investigate -sourcepath usage when compiling java In-Reply-To: <54859509.3040402@oracle.com> References: <54859509.3040402@oracle.com> Message-ID: <5485AF87.30303@oracle.com> On 08/12/2014 12:09, Erik Joelsson wrote: > Hello, > > Please review this fix, removing the use of -sourcepath when compiling > java sources. For a long time, all java compilation lines have > included a -sourcepath parameter. We have now concluded that > in some cases it's just wrong and the rest of the cases it's just > unnecessary. > > I have tried building with and without this patch and enabling sjavac, > and the class file output is equivalent in all cases. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066761 > Webrev: http://cr.openjdk.java.net/~erikj/8066761/webrev.01/ This seems right to me but still confusing as to why -sourcepath was used in the first place. -Alan From magnus.ihse.bursie at oracle.com Mon Dec 8 14:53:44 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 08 Dec 2014 15:53:44 +0100 Subject: RFR: JDK-8066761: Investigate -sourcepath usage when compiling java In-Reply-To: <54859509.3040402@oracle.com> References: <54859509.3040402@oracle.com> Message-ID: <5485BB78.8030300@oracle.com> On 2014-12-08 13:09, Erik Joelsson wrote: > Hello, > > Please review this fix, removing the use of -sourcepath when compiling > java sources. For a long time, all java compilation lines have > included a -sourcepath parameter. We have now concluded that > in some cases it's just wrong and the rest of the cases it's just > unnecessary. > > I have tried building with and without this patch and enabling sjavac, > and the class file output is equivalent in all cases. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066761 > Webrev: http://cr.openjdk.java.net/~erikj/8066761/webrev.01/ Looks good to me. Good riddance! /Magnus From magnus.ihse.bursie at oracle.com Mon Dec 8 14:54:40 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 08 Dec 2014 15:54:40 +0100 Subject: RFR: JDK-8066752: Remove space after -L on linker lines In-Reply-To: <5485AD4E.7020504@oracle.com> References: <5485AD4E.7020504@oracle.com> Message-ID: <5485BBB0.8060900@oracle.com> On 2014-12-08 14:53, Erik Joelsson wrote: > Hello, > > Please review this small patch, removing all instances of space > following '-L' on linker lines. With certain versions of XCode on > Macosx, this results in an error. Most of these instances were > introduced with the modular images change. I chose to remove > everything I could find, even if not used on Macosx builds, for > consistency. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066752 > Webrev: http://cr.openjdk.java.net/~erikj/8066752/webrev.jdk.01/ > > /Erik Looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Mon Dec 8 15:05:05 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 08 Dec 2014 16:05:05 +0100 Subject: RFR: JDK-8066828: configure fails if it's set --with-boot-jdk to use JDK 9 modular image In-Reply-To: <548586D2.4060602@oracle.com> References: <548586D2.4060602@oracle.com> Message-ID: <5485BE21.9030401@oracle.com> On 2014-12-08 12:09, Erik Joelsson wrote: > Hello, > > Please review this fix to configure, removing the requirement that the > bootjdk has an rt.jar. In the modular images change, we already did > away with using the rt.jar in the boot jdk. With this fix, it becomes > possible to use a modular image as boot jdk when building JDK 9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066828 > Webrev: http://cr.openjdk.java.net/~erikj/8066828/webrev.root.01/ Looks good to me. /Magnus From jonathan.gibbons at oracle.com Mon Dec 8 17:42:12 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 08 Dec 2014 09:42:12 -0800 Subject: RFR: JDK-8066761: Investigate -sourcepath usage when compiling java In-Reply-To: <5485BB78.8030300@oracle.com> References: <54859509.3040402@oracle.com> <5485BB78.8030300@oracle.com> Message-ID: <5485E2F4.5060600@oracle.com> On 12/08/2014 06:53 AM, Magnus Ihse Bursie wrote: > On 2014-12-08 13:09, Erik Joelsson wrote: >> Hello, >> >> Please review this fix, removing the use of -sourcepath when >> compiling java sources. For a long time, all java compilation lines >> have included a -sourcepath parameter. We have now concluded >> that in some cases it's just wrong and the rest of the cases it's >> just unnecessary. >> >> I have tried building with and without this patch and enabling >> sjavac, and the class file output is equivalent in all cases. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8066761 >> Webrev: http://cr.openjdk.java.net/~erikj/8066761/webrev.01/ > > Looks good to me. Good riddance! > > /Magnus It is possible that -sourcepath is a hangover from the recusive-make days, when we built JDK package-by-package. -- Jon From david.holmes at oracle.com Tue Dec 9 09:11:33 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Dec 2014 19:11:33 +1000 Subject: Windows compilation problem Message-ID: <5486BCC5.9070505@oracle.com> This is driving me nuts :) Here's the code from start of file (header excluded): #include "utilities/macros.hpp" #if INCLUDE_NMT #include "precompiled.hpp" #include "oops/instanceKlass.hpp" #include "runtime/atomic.hpp" #include "runtime/interfaceSupport.hpp" #include "runtime/mutexLocker.hpp" #include "runtime/safepoint.hpp" #include "runtime/threadCritical.hpp" #include "runtime/vm_operations.hpp" #include "services/memPtr.hpp" #include "services/memReporter.hpp" #endif #include "services/memTracker.hpp" And here's the error: C:\jprt\T\P1\085339.daholme\s\hotspot\src\share\vm\services\memTracker.cpp(38) : fatal error C1020: unexpected #endif ??? 8u codebase. Any insight appreciated. Thanks, David From sgehwolf at redhat.com Tue Dec 9 09:27:06 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 09 Dec 2014 10:27:06 +0100 Subject: How to cross compile OpenJDK for Arm32? In-Reply-To: <54858F7F.6060707@oracle.com> References: <54858F7F.6060707@oracle.com> Message-ID: <1418117226.3210.5.camel@localhost.localdomain> Hi, On Mon, 2014-12-08 at 21:46 +1000, David Holmes wrote: > On 8/12/2014 7:10 PM, ChenLong wrote: > > Hi > > > > Apologize if this is not the right place to ask. > > I want to try OpenJDK8 on Armv7. Is there a guideline on how to cross compile OpenJDK8 for Armv7? And if not, could someone share some experiences? I went through the README-builds.html and did not find any clues for cross compiling. > > The only OpenJDK build for ARM would be a ZERO build. But I don't know > how to do Zero builds - though I'm sure the Zero folk will chime in. CC'ing zero-dev. I've done Zero builds before but have never used OpenJDK's cross-compile feature to build it on ARMv7. There is an Arm32 bit JIT in IcedTea[1], but I don't know if that can be cross-compiled. Cheers, Severin [1] http://blog.fuseyism.com/index.php/2014/03/28/icedtea-2-3-14-2-4-6-considered-armful-released/ > David > > > Thanks > > Chen Long > > From xerxes at zafena.se Tue Dec 9 11:16:10 2014 From: xerxes at zafena.se (=?UTF-8?B?WGVyeGVzIFLDpW5ieQ==?=) Date: Tue, 09 Dec 2014 12:16:10 +0100 Subject: How to cross compile OpenJDK for Arm32? In-Reply-To: <1418117226.3210.5.camel@localhost.localdomain> References: <54858F7F.6060707@oracle.com> <1418117226.3210.5.camel@localhost.localdomain> Message-ID: <5486D9FA.9050606@zafena.se> Den 2014-12-09 10:27, Severin Gehwolf skrev: > Hi, > > On Mon, 2014-12-08 at 21:46 +1000, David Holmes wrote: >> On 8/12/2014 7:10 PM, ChenLong wrote: >>> Hi >>> >>> Apologize if this is not the right place to ask. >>> I want to try OpenJDK8 on Armv7. Is there a guideline on how to cross compile OpenJDK8 for Armv7? And if not, could someone share some experiences? I went through the README-builds.html and did not find any clues for cross compiling. >> The only OpenJDK build for ARM would be a ZERO build. But I don't know >> how to do Zero builds - though I'm sure the Zero folk will chime in. > CC'ing zero-dev. when I cross-compile OpenJDK 9 for ARM32 I pass the following configure options configure # these options tell openjdk to do a cross compile build. --build=x86_64-unknown-linux-gnu --host=arm-buildroot-linux-gnueabi --target=arm-buildroot-linux-gnueabi # these two options enable zero --with-jvm-interpreter=cpp --with-jvm-variants=zero # specific options to make the build find the X and freetype headers and librarys found on the ARM32 root filesystem. --disable-freetype-bundling --with-freetype-include=/home/xranby/rpi-buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/freetype2 --with-freetype-lib=/home/xranby/rpi-buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib --with-freetype=/home/xranby/rpi-buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/ --with-x=/home/xranby/rpi-buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include # the sysroot shall point to the ARM32 root file system, the build will use librarys inside the sys root during linking native libraries. --with-sys-root=/home/xranby/rpi-buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot # The tools dir contains binarys to run on the host x86 system, you may point this to your system root dir / # in my case the tools i use have been compiled by buildroot thus I use the buildroot tools dir. --with-tools-dir=/home/xranby/rpi-buildroot/output/host # OpenJDK 9 require OpenJDK 8, i point with boot jdk to an OpenJDK 8 image that can be run on the host x86 system. --with-boot-jdk=/home/xranby/images-jdk8/j2sdk-image/ # some parts of the openjdk build still expect that the cross compile tools are found in the system PATH # on my system i have to explicitly tell where the tools are located because my cross compile toolchain is not found on the path. # i use gcc to do the linking instead of ld because the openjdk build passes -Xlinker -z OBJCOPY=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-objcopy STRIP=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-strip CPP=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-cpp CXX=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-g++ CC=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc LD=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc CPP_FLAGS=-lstdc++ CXX_FLAGS=-lstdc++ when running make i pass the following options to make # BUILD_CC and BUILD_LD shall point to host x86 executables. BUILD_CC=gcc BUILD_LD=gcc OBJCOPY=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-objcopy STRIP=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-strip CPP=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-cpp CXX=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-g++ CC=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc LD=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc #and finally the target, this will build compact profiles, jre and jdk images. all images profiles CONF=linux-arm-normal-zero-release I have automated these configure and make options for openjdk 9 into buildroot build scripts https://github.com/xranby/rpi-buildroot/tree/openjdk > > I've done Zero builds before but have never used OpenJDK's cross-compile > feature to build it on ARMv7. There is an Arm32 bit JIT in IcedTea[1], > but I don't know if that can be cross-compiled. If you cross compile icedtea then you need to make sure that the bytecode generator tool is compiled by the host x86 toolchain. openembedded meta-java contains buildscripts that can cross compile the Arm32 JIT found in IcedTea. https://github.com/woglinde/meta-java Cheers Xerxes > > Cheers, > Severin > > [1] > http://blog.fuseyism.com/index.php/2014/03/28/icedtea-2-3-14-2-4-6-considered-armful-released/ > >> David >> >>> Thanks >>> Chen Long >>> > > From thomas.stuefe at gmail.com Tue Dec 9 11:59:02 2014 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 9 Dec 2014 12:59:02 +0100 Subject: Windows compilation problem In-Reply-To: <5486BCC5.9070505@oracle.com> References: <5486BCC5.9070505@oracle.com> Message-ID: Hi David, Everything before the precompiled header gets ignored, I think. Cheers, Thomas On Dec 9, 2014 10:12 AM, "David Holmes" wrote: > This is driving me nuts :) > > Here's the code from start of file (header excluded): > > #include "utilities/macros.hpp" > > #if INCLUDE_NMT > #include "precompiled.hpp" > > #include "oops/instanceKlass.hpp" > #include "runtime/atomic.hpp" > #include "runtime/interfaceSupport.hpp" > #include "runtime/mutexLocker.hpp" > #include "runtime/safepoint.hpp" > #include "runtime/threadCritical.hpp" > #include "runtime/vm_operations.hpp" > #include "services/memPtr.hpp" > #include "services/memReporter.hpp" > #endif > #include "services/memTracker.hpp" > > And here's the error: > > C:\jprt\T\P1\085339.daholme\s\hotspot\src\share\vm\services\memTracker.cpp(38) > : fatal error C1020: unexpected #endif > > ??? > > 8u codebase. > > Any insight appreciated. > > Thanks, > David > From volker.simonis at gmail.com Tue Dec 9 17:12:33 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 9 Dec 2014 18:12:33 +0100 Subject: RFR(XS): 8066589: Make importing sa-jdi.jar optional on its existance In-Reply-To: <548176B3.3040707@oracle.com> References: <548176B3.3040707@oracle.com> Message-ID: On Fri, Dec 5, 2014 at 10:11 AM, Erik Joelsson wrote: > Hello Volker, > > Are these the only conditions for when sa-jdi.jar is not built? If so, then > I suppose this is fine. Yes. But with my proposed solution any new platform may easily add itself to the list of platforms which don't have the SA-agent. > > The old Import.gmk would only copy sa-jdi.jar if it existed, and I think we > can keep that behavior, so just an existence check on sa-jdi.jar is good > enough in Import.gmk. In Gensrc-jdk.jdi.gmk, checking if > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services exists should > be fine with me. We lose a bit of error checking in the build doing it that > way as we won't fail if that file is missing for other reasons. > I don't quite understand. If a platform doesn't support the SA-agent there's no need for any error checking. This fix doesn't change the behaviour on any other platform except for aix-ppc64 and ZERO. Any other platforms which don't support the SA just add themselves to the lisst in the if-statement without affecting the other platforms. > Note that this hacking of the service provider files is a temporary hack > until service providers are properly handled in the modular world, so no > need for fancy solutions. OK fine. I've added one more tiny fix which was needed to build on AIX. It's in an if-def AIX anyway, so it won't impact other platforms. It just fixes the location of the static version of libjli: http://cr.openjdk.java.net/~simonis/webrevs/8066589.v2/ OK to push now? Thanks, Volker > > /Erik > > > On 2014-12-04 18:49, Volker Simonis wrote: >> >> Hi, >> >> could you please review this tiny change which fixes the build on >> platforms which don't built the SA agent after the recent modualrity >> integrations: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8066589 >> https://bugs.openjdk.java.net/browse/JDK-8066589 >> >> I've tested that the fix works on AIX but I havn't had a chance to build >> Zero. >> >> @Xerxes: maybe you could check if my suggested fix also solves your >> build problems. I'm also no sure if the "ifneq ($(JVM_VARIANT_ZERO), >> true)" clause also catches the ZEROSHARK case (altough I think it >> should). If not we would need yet another "ifneq >> ($(JVM_VARIANT_ZEROSHARK), true)" >> >> Thanks, >> Volker > > From dmitry.samersoff at oracle.com Tue Dec 9 17:23:46 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 09 Dec 2014 20:23:46 +0300 Subject: RFR(XS): 8066589: Make importing sa-jdi.jar optional on its existance In-Reply-To: References: <548176B3.3040707@oracle.com> Message-ID: <54873022.2030304@oracle.com> Volker, Please notice, there is work-in-progress to cease out any dependencies to jdk.hotspot.agent from other modules. Please, see: https://bugs.openjdk.java.net/browse/JDK-8059038 https://bugs.openjdk.java.net/browse/JDK-8059035 -Dmitry On 2014-12-09 20:12, Volker Simonis wrote: > On Fri, Dec 5, 2014 at 10:11 AM, Erik Joelsson wrote: >> Hello Volker, >> >> Are these the only conditions for when sa-jdi.jar is not built? If so, then >> I suppose this is fine. > > Yes. But with my proposed solution any new platform may easily add > itself to the list of platforms which don't have the SA-agent. > >> >> The old Import.gmk would only copy sa-jdi.jar if it existed, and I think we >> can keep that behavior, so just an existence check on sa-jdi.jar is good >> enough in Import.gmk. In Gensrc-jdk.jdi.gmk, checking if >> $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services exists should >> be fine with me. We lose a bit of error checking in the build doing it that >> way as we won't fail if that file is missing for other reasons. >> > > I don't quite understand. If a platform doesn't support the SA-agent > there's no need for any error checking. This fix doesn't change the > behaviour on any other platform except for aix-ppc64 and ZERO. Any > other platforms which don't support the SA just add themselves to the > lisst in the if-statement without affecting the other platforms. > > > >> Note that this hacking of the service provider files is a temporary hack >> until service providers are properly handled in the modular world, so no >> need for fancy solutions. > > OK fine. I've added one more tiny fix which was needed to build on > AIX. It's in an if-def AIX anyway, so it won't impact other platforms. > It just fixes the location of the static version of libjli: > > http://cr.openjdk.java.net/~simonis/webrevs/8066589.v2/ > > OK to push now? > > Thanks, > Volker > >> >> /Erik >> >> >> On 2014-12-04 18:49, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review this tiny change which fixes the build on >>> platforms which don't built the SA agent after the recent modualrity >>> integrations: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8066589 >>> https://bugs.openjdk.java.net/browse/JDK-8066589 >>> >>> I've tested that the fix works on AIX but I havn't had a chance to build >>> Zero. >>> >>> @Xerxes: maybe you could check if my suggested fix also solves your >>> build problems. I'm also no sure if the "ifneq ($(JVM_VARIANT_ZERO), >>> true)" clause also catches the ZEROSHARK case (altough I think it >>> should). If not we would need yet another "ifneq >>> ($(JVM_VARIANT_ZEROSHARK), true)" >>> >>> Thanks, >>> Volker >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From volker.simonis at gmail.com Tue Dec 9 17:42:29 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 9 Dec 2014 18:42:29 +0100 Subject: RFR(XS): 8066589: Make importing sa-jdi.jar optional on its existance In-Reply-To: <54873022.2030304@oracle.com> References: <548176B3.3040707@oracle.com> <54873022.2030304@oracle.com> Message-ID: That's fine, but we currently can not build on AIX because of this issue and I don't want to stay without builds until the mentioned bugs are fixed (especially when the fix for the issue is so simple and non-intrusive for other platforms). Regards, Volker On Tue, Dec 9, 2014 at 6:23 PM, Dmitry Samersoff wrote: > Volker, > > Please notice, there is work-in-progress to cease out any dependencies > to jdk.hotspot.agent from other modules. > > > Please, see: > > https://bugs.openjdk.java.net/browse/JDK-8059038 > https://bugs.openjdk.java.net/browse/JDK-8059035 > > -Dmitry > > > On 2014-12-09 20:12, Volker Simonis wrote: >> On Fri, Dec 5, 2014 at 10:11 AM, Erik Joelsson wrote: >>> Hello Volker, >>> >>> Are these the only conditions for when sa-jdi.jar is not built? If so, then >>> I suppose this is fine. >> >> Yes. But with my proposed solution any new platform may easily add >> itself to the list of platforms which don't have the SA-agent. >> >>> >>> The old Import.gmk would only copy sa-jdi.jar if it existed, and I think we >>> can keep that behavior, so just an existence check on sa-jdi.jar is good >>> enough in Import.gmk. In Gensrc-jdk.jdi.gmk, checking if >>> $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services exists should >>> be fine with me. We lose a bit of error checking in the build doing it that >>> way as we won't fail if that file is missing for other reasons. >>> >> >> I don't quite understand. If a platform doesn't support the SA-agent >> there's no need for any error checking. This fix doesn't change the >> behaviour on any other platform except for aix-ppc64 and ZERO. Any >> other platforms which don't support the SA just add themselves to the >> lisst in the if-statement without affecting the other platforms. >> >> >> >>> Note that this hacking of the service provider files is a temporary hack >>> until service providers are properly handled in the modular world, so no >>> need for fancy solutions. >> >> OK fine. I've added one more tiny fix which was needed to build on >> AIX. It's in an if-def AIX anyway, so it won't impact other platforms. >> It just fixes the location of the static version of libjli: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8066589.v2/ >> >> OK to push now? >> >> Thanks, >> Volker >> >>> >>> /Erik >>> >>> >>> On 2014-12-04 18:49, Volker Simonis wrote: >>>> >>>> Hi, >>>> >>>> could you please review this tiny change which fixes the build on >>>> platforms which don't built the SA agent after the recent modualrity >>>> integrations: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8066589 >>>> https://bugs.openjdk.java.net/browse/JDK-8066589 >>>> >>>> I've tested that the fix works on AIX but I havn't had a chance to build >>>> Zero. >>>> >>>> @Xerxes: maybe you could check if my suggested fix also solves your >>>> build problems. I'm also no sure if the "ifneq ($(JVM_VARIANT_ZERO), >>>> true)" clause also catches the ZEROSHARK case (altough I think it >>>> should). If not we would need yet another "ifneq >>>> ($(JVM_VARIANT_ZEROSHARK), true)" >>>> >>>> Thanks, >>>> Volker >>> >>> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Tue Dec 9 19:01:39 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 09 Dec 2014 22:01:39 +0300 Subject: RFR(XS): 8066589: Make importing sa-jdi.jar optional on its existance In-Reply-To: References: <548176B3.3040707@oracle.com> <54873022.2030304@oracle.com> Message-ID: <54874713.9040401@oracle.com> Volker, I'm OK with your fix. -Dmitry On 2014-12-09 20:42, Volker Simonis wrote: > That's fine, but we currently can not build on AIX because of this > issue and I don't want to stay without builds until the mentioned bugs > are fixed (especially when the fix for the issue is so simple and > non-intrusive for other platforms). > > Regards, > Volker > > On Tue, Dec 9, 2014 at 6:23 PM, Dmitry Samersoff > wrote: >> Volker, >> >> Please notice, there is work-in-progress to cease out any dependencies >> to jdk.hotspot.agent from other modules. >> >> >> Please, see: >> >> https://bugs.openjdk.java.net/browse/JDK-8059038 >> https://bugs.openjdk.java.net/browse/JDK-8059035 >> >> -Dmitry >> >> >> On 2014-12-09 20:12, Volker Simonis wrote: >>> On Fri, Dec 5, 2014 at 10:11 AM, Erik Joelsson wrote: >>>> Hello Volker, >>>> >>>> Are these the only conditions for when sa-jdi.jar is not built? If so, then >>>> I suppose this is fine. >>> >>> Yes. But with my proposed solution any new platform may easily add >>> itself to the list of platforms which don't have the SA-agent. >>> >>>> >>>> The old Import.gmk would only copy sa-jdi.jar if it existed, and I think we >>>> can keep that behavior, so just an existence check on sa-jdi.jar is good >>>> enough in Import.gmk. In Gensrc-jdk.jdi.gmk, checking if >>>> $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services exists should >>>> be fine with me. We lose a bit of error checking in the build doing it that >>>> way as we won't fail if that file is missing for other reasons. >>>> >>> >>> I don't quite understand. If a platform doesn't support the SA-agent >>> there's no need for any error checking. This fix doesn't change the >>> behaviour on any other platform except for aix-ppc64 and ZERO. Any >>> other platforms which don't support the SA just add themselves to the >>> lisst in the if-statement without affecting the other platforms. >>> >>> >>> >>>> Note that this hacking of the service provider files is a temporary hack >>>> until service providers are properly handled in the modular world, so no >>>> need for fancy solutions. >>> >>> OK fine. I've added one more tiny fix which was needed to build on >>> AIX. It's in an if-def AIX anyway, so it won't impact other platforms. >>> It just fixes the location of the static version of libjli: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8066589.v2/ >>> >>> OK to push now? >>> >>> Thanks, >>> Volker >>> >>>> >>>> /Erik >>>> >>>> >>>> On 2014-12-04 18:49, Volker Simonis wrote: >>>>> >>>>> Hi, >>>>> >>>>> could you please review this tiny change which fixes the build on >>>>> platforms which don't built the SA agent after the recent modualrity >>>>> integrations: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8066589 >>>>> https://bugs.openjdk.java.net/browse/JDK-8066589 >>>>> >>>>> I've tested that the fix works on AIX but I havn't had a chance to build >>>>> Zero. >>>>> >>>>> @Xerxes: maybe you could check if my suggested fix also solves your >>>>> build problems. I'm also no sure if the "ifneq ($(JVM_VARIANT_ZERO), >>>>> true)" clause also catches the ZEROSHARK case (altough I think it >>>>> should). If not we would need yet another "ifneq >>>>> ($(JVM_VARIANT_ZEROSHARK), true)" >>>>> >>>>> Thanks, >>>>> Volker >>>> >>>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Tue Dec 9 19:30:55 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Dec 2014 05:30:55 +1000 Subject: Windows compilation problem In-Reply-To: References: <5486BCC5.9070505@oracle.com> Message-ID: <54874DEF.8060602@oracle.com> Hi Thomas, On 9/12/2014 9:59 PM, Thomas St?fe wrote: > Hi David, > > Everything before the precompiled header gets ignored, I think. Thank you! Now I recall that little detail on windows. David > Cheers, Thomas > > On Dec 9, 2014 10:12 AM, "David Holmes" > wrote: > > This is driving me nuts :) > > Here's the code from start of file (header excluded): > > #include "utilities/macros.hpp" > > #if INCLUDE_NMT > #include "precompiled.hpp" > > #include "oops/instanceKlass.hpp" > #include "runtime/atomic.hpp" > #include "runtime/interfaceSupport.hpp" > #include "runtime/mutexLocker.hpp" > #include "runtime/safepoint.hpp" > #include "runtime/threadCritical.hpp" > #include "runtime/vm_operations.hpp" > #include "services/memPtr.hpp" > #include "services/memReporter.hpp" > #endif > #include "services/memTracker.hpp" > > And here's the error: > > C:\jprt\T\P1\085339.daholme\s\__hotspot\src\share\vm\services\__memTracker.cpp(38) > : fatal error C1020: unexpected #endif > > ??? > > 8u codebase. > > Any insight appreciated. > > Thanks, > David > From joe.darcy at oracle.com Wed Dec 10 01:59:44 2014 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 09 Dec 2014 17:59:44 -0800 Subject: JDK 9 RFR of JDK-8067099: Add deprecation lint warning to build of jdk repository Message-ID: <5487A910.9000504@oracle.com> Hello, The time approaches when the one remaining category of lint warning still present in the jdk repo, deprecation, will be eliminated. In anticipation of that happy day, please review this simple patch to enable the warning in the build: diff -r f7c11da0b048 make/common/SetupJavaCompilers.gmk --- a/make/common/SetupJavaCompilers.gmk Thu Dec 04 15:21:09 2014 -0800 +++ b/make/common/SetupJavaCompilers.gmk Tue Dec 09 17:30:32 2014 -0800 @@ -32,7 +32,7 @@ # To build with all warnings enabled, do the following: # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" -JAVAC_WARNINGS := -Xlint:all,-deprecation -Werror +JAVAC_WARNINGS := -Xlint:all -Werror # The BOOT_JAVAC setup uses the boot jdk compiler to compile the tools # and the interim javac, to be run by the boot jdk. As usual for this kind of change, a jprt job will be used to verify the fix is valid on all platforms, etc. Thanks, -Joe From chlict at gmail.com Wed Dec 10 03:29:29 2014 From: chlict at gmail.com (ChenLong) Date: Wed, 10 Dec 2014 11:29:29 +0800 Subject: How to cross compile OpenJDK for Arm32? Message-ID: Thanks a lot for sharing these! It seems a lot of efforts needed to cross-compiling OpenJDK (I do hope it could be easier :). A couple of more quick questions: 1) Is it same as OpenJDK 8? (I prefer 8 as it is the latest release, right?) 2) Is there any place that I can download prebuilt sysroot/rootfs? That would be great helpful. 3) Can you give me more hints on "bytecode generator tool" compilation? I'm not familiar with this.. Chen Long Xerxes R?nby ??? > >Den 2014-12-09 10:27, Severin Gehwolf skrev: >> Hi, >> >> On Mon, 2014-12-08 at 21:46 +1000, David Holmes wrote: >>> On 8/12/2014 7:10 PM, ChenLong wrote: >>>> Hi >>>> >>>> Apologize if this is not the right place to ask. >>>> I want to try OpenJDK8 on Armv7. Is there a guideline on how to cross compile OpenJDK8 for Armv7? And if not, could someone share some experiences? I went through the README-builds.html and did not find any clues for cross compiling. >>> The only OpenJDK build for ARM would be a ZERO build. But I don't know >>> how to do Zero builds - though I'm sure the Zero folk will chime in. >> CC'ing zero-dev. > >when I cross-compile OpenJDK 9 for ARM32 I pass the following configure >options > >configure ># these options tell openjdk to do a cross compile build. >--build=x86_64-unknown-linux-gnu >--host=arm-buildroot-linux-gnueabi >--target=arm-buildroot-linux-gnueabi > ># these two options enable zero >--with-jvm-interpreter=cpp >--with-jvm-variants=zero > ># specific options to make the build find the X and freetype headers and >librarys found on the ARM32 root filesystem. >--disable-freetype-bundling >--with-freetype-include=/home/xranby/rpi-buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/freetype2 >--with-freetype-lib=/home/xranby/rpi-buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib >--with-freetype=/home/xranby/rpi-buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/ >--with-x=/home/xranby/rpi-buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include > ># the sysroot shall point to the ARM32 root file system, the build will >use librarys inside the sys root during linking native libraries. >--with-sys-root=/home/xranby/rpi-buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot ># The tools dir contains binarys to run on the host x86 system, you may >point this to your system root dir / ># in my case the tools i use have been compiled by buildroot thus I use >the buildroot tools dir. >--with-tools-dir=/home/xranby/rpi-buildroot/output/host ># OpenJDK 9 require OpenJDK 8, i point with boot jdk to an OpenJDK 8 >image that can be run on the host x86 system. >--with-boot-jdk=/home/xranby/images-jdk8/j2sdk-image/ > ># some parts of the openjdk build still expect that the cross compile >tools are found in the system PATH ># on my system i have to explicitly tell where the tools are located >because my cross compile toolchain is not found on the path. ># i use gcc to do the linking instead of ld because the openjdk build >passes -Xlinker -z >OBJCOPY=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-objcopy >STRIP=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-strip >CPP=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-cpp >CXX=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-g++ >CC=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc >LD=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc >CPP_FLAGS=-lstdc++ >CXX_FLAGS=-lstdc++ > > >when running make i pass the following options to make ># BUILD_CC and BUILD_LD shall point to host x86 executables. >BUILD_CC=gcc >BUILD_LD=gcc >OBJCOPY=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-objcopy >STRIP=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-strip >CPP=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-cpp >CXX=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-g++ >CC=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc >LD=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc >#and finally the target, this will build compact profiles, jre and jdk >images. >all images profiles CONF=linux-arm-normal-zero-release > > >I have automated these configure and make options for openjdk 9 into >buildroot build scripts >https://github.com/xranby/rpi-buildroot/tree/openjdk > >> >> I've done Zero builds before but have never used OpenJDK's cross-compile >> feature to build it on ARMv7. There is an Arm32 bit JIT in IcedTea[1], >> but I don't know if that can be cross-compiled. > >If you cross compile icedtea then you need to make sure that the >bytecode generator tool is compiled by the host x86 toolchain. >openembedded meta-java contains buildscripts that can cross compile the >Arm32 JIT found in IcedTea. >https://github.com/woglinde/meta-java > >Cheers >Xerxes > >> >> Cheers, >> Severin >> >> [1] >> http://blog.fuseyism.com/index.php/2014/03/28/icedtea-2-3-14-2-4-6-considered-armful-released/ >> >>> David >>> >>>> Thanks >>>> Chen Long >>>> >> >> > From david.holmes at oracle.com Wed Dec 10 06:06:47 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Dec 2014 16:06:47 +1000 Subject: How to cross compile OpenJDK for Arm32? In-Reply-To: <5486D9FA.9050606@zafena.se> References: <54858F7F.6060707@oracle.com> <1418117226.3210.5.camel@localhost.localdomain> <5486D9FA.9050606@zafena.se> Message-ID: <5487E2F7.7000601@oracle.com> On 9/12/2014 9:16 PM, Xerxes R?nby wrote: > > Den 2014-12-09 10:27, Severin Gehwolf skrev: >> Hi, >> >> On Mon, 2014-12-08 at 21:46 +1000, David Holmes wrote: >>> On 8/12/2014 7:10 PM, ChenLong wrote: >>>> Hi >>>> >>>> Apologize if this is not the right place to ask. >>>> I want to try OpenJDK8 on Armv7. Is there a guideline on how to >>>> cross compile OpenJDK8 for Armv7? And if not, could someone share >>>> some experiences? I went through the README-builds.html and did not >>>> find any clues for cross compiling. >>> The only OpenJDK build for ARM would be a ZERO build. But I don't know >>> how to do Zero builds - though I'm sure the Zero folk will chime in. >> CC'ing zero-dev. > > when I cross-compile OpenJDK 9 for ARM32 I pass the following configure > options > > configure > # these options tell openjdk to do a cross compile build. > --build=x86_64-unknown-linux-gnu > --host=arm-buildroot-linux-gnueabi > --target=arm-buildroot-linux-gnueabi > > # these two options enable zero > --with-jvm-interpreter=cpp > --with-jvm-variants=zero > > # specific options to make the build find the X and freetype headers and > librarys found on the ARM32 root filesystem. > --disable-freetype-bundling > --with-freetype-include=/home/xranby/rpi-buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/freetype2 > > --with-freetype-lib=/home/xranby/rpi-buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib > > --with-freetype=/home/xranby/rpi-buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/ > > --with-x=/home/xranby/rpi-buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include > > > # the sysroot shall point to the ARM32 root file system, the build will > use librarys inside the sys root during linking native libraries. > --with-sys-root=/home/xranby/rpi-buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot > > # The tools dir contains binarys to run on the host x86 system, you may > point this to your system root dir / > # in my case the tools i use have been compiled by buildroot thus I use > the buildroot tools dir. > --with-tools-dir=/home/xranby/rpi-buildroot/output/host > # OpenJDK 9 require OpenJDK 8, i point with boot jdk to an OpenJDK 8 > image that can be run on the host x86 system. > --with-boot-jdk=/home/xranby/images-jdk8/j2sdk-image/ > > # some parts of the openjdk build still expect that the cross compile > tools are found in the system PATH No that should not be the case. If you have set the tools-dir or --with-devkit to point to your cross-compiler tool-chain then it will use those without need to set all the build tool variables manually. David ----- > # on my system i have to explicitly tell where the tools are located > because my cross compile toolchain is not found on the path. > # i use gcc to do the linking instead of ld because the openjdk build > passes -Xlinker -z > OBJCOPY=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-objcopy > > STRIP=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-strip > > CPP=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-cpp > > CXX=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-g++ > > CC=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc > > LD=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc > > CPP_FLAGS=-lstdc++ > CXX_FLAGS=-lstdc++ > > > when running make i pass the following options to make > # BUILD_CC and BUILD_LD shall point to host x86 executables. > BUILD_CC=gcc > BUILD_LD=gcc > OBJCOPY=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-objcopy > > STRIP=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-strip > > CPP=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-cpp > > CXX=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-g++ > > CC=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc > > LD=/home/xranby/rpi-buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc > > #and finally the target, this will build compact profiles, jre and jdk > images. > all images profiles CONF=linux-arm-normal-zero-release > > > I have automated these configure and make options for openjdk 9 into > buildroot build scripts > https://github.com/xranby/rpi-buildroot/tree/openjdk > >> >> I've done Zero builds before but have never used OpenJDK's cross-compile >> feature to build it on ARMv7. There is an Arm32 bit JIT in IcedTea[1], >> but I don't know if that can be cross-compiled. > > If you cross compile icedtea then you need to make sure that the > bytecode generator tool is compiled by the host x86 toolchain. > openembedded meta-java contains buildscripts that can cross compile the > Arm32 JIT found in IcedTea. > https://github.com/woglinde/meta-java > > Cheers > Xerxes > >> >> Cheers, >> Severin >> >> [1] >> http://blog.fuseyism.com/index.php/2014/03/28/icedtea-2-3-14-2-4-6-considered-armful-released/ >> >> >>> David >>> >>>> Thanks >>>> Chen Long >>>> >> >> > From erik.joelsson at oracle.com Wed Dec 10 06:35:23 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Dec 2014 07:35:23 +0100 Subject: RFR(XS): 8066589: Make importing sa-jdi.jar optional on its existance In-Reply-To: References: <548176B3.3040707@oracle.com> Message-ID: <5487E9AB.20805@oracle.com> On 2014-12-09 18:12, Volker Simonis wrote: > On Fri, Dec 5, 2014 at 10:11 AM, Erik Joelsson wrote: >> Hello Volker, >> >> Are these the only conditions for when sa-jdi.jar is not built? If so, then >> I suppose this is fine. > Yes. But with my proposed solution any new platform may easily add > itself to the list of platforms which don't have the SA-agent. > >> The old Import.gmk would only copy sa-jdi.jar if it existed, and I think we >> can keep that behavior, so just an existence check on sa-jdi.jar is good >> enough in Import.gmk. In Gensrc-jdk.jdi.gmk, checking if >> $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services exists should >> be fine with me. We lose a bit of error checking in the build doing it that >> way as we won't fail if that file is missing for other reasons. >> > I don't quite understand. If a platform doesn't support the SA-agent > there's no need for any error checking. This fix doesn't change the > behaviour on any other platform except for aix-ppc64 and ZERO. Any > other platforms which don't support the SA just add themselves to the > lisst in the if-statement without affecting the other platforms. > What I meant with the "old Import.gmk" is the version before modular images change. In that version, there was no error checking, sa-jdi.jar would just get copied if it existed and otherwise not. In the current version of Import.gmk, the build fails if it's not there. What I tried to say was, it would be ok if your change made it so that simply the existence of sa-jdi.jar was controlling this logic. But I'm fine with this solution too. > >> Note that this hacking of the service provider files is a temporary hack >> until service providers are properly handled in the modular world, so no >> need for fancy solutions. > OK fine. I've added one more tiny fix which was needed to build on > AIX. It's in an if-def AIX anyway, so it won't impact other platforms. > It just fixes the location of the static version of libjli: > > http://cr.openjdk.java.net/~simonis/webrevs/8066589.v2/ > > OK to push now? Please do. Looks ok to me. /Erik > Thanks, > Volker > >> /Erik >> >> >> On 2014-12-04 18:49, Volker Simonis wrote: >>> Hi, >>> >>> could you please review this tiny change which fixes the build on >>> platforms which don't built the SA agent after the recent modualrity >>> integrations: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8066589 >>> https://bugs.openjdk.java.net/browse/JDK-8066589 >>> >>> I've tested that the fix works on AIX but I havn't had a chance to build >>> Zero. >>> >>> @Xerxes: maybe you could check if my suggested fix also solves your >>> build problems. I'm also no sure if the "ifneq ($(JVM_VARIANT_ZERO), >>> true)" clause also catches the ZEROSHARK case (altough I think it >>> should). If not we would need yet another "ifneq >>> ($(JVM_VARIANT_ZEROSHARK), true)" >>> >>> Thanks, >>> Volker >> From erik.joelsson at oracle.com Wed Dec 10 06:39:57 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Dec 2014 07:39:57 +0100 Subject: JDK 9 RFR of JDK-8067099: Add deprecation lint warning to build of jdk repository In-Reply-To: <5487A910.9000504@oracle.com> References: <5487A910.9000504@oracle.com> Message-ID: <5487EABD.7060509@oracle.com> First, congratulations on almost being done fixing all the warnings! When removing the last warning exception, perhaps it's time to change the comment next to this line too? /Erik On 2014-12-10 02:59, joe darcy wrote: > Hello, > > The time approaches when the one remaining category of lint warning > still present in the jdk repo, deprecation, will be eliminated. In > anticipation of that happy day, please review this simple patch to > enable the warning in the build: > > diff -r f7c11da0b048 make/common/SetupJavaCompilers.gmk > --- a/make/common/SetupJavaCompilers.gmk Thu Dec 04 15:21:09 2014 > -0800 > +++ b/make/common/SetupJavaCompilers.gmk Tue Dec 09 17:30:32 2014 > -0800 > @@ -32,7 +32,7 @@ > > # To build with all warnings enabled, do the following: > # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" > -JAVAC_WARNINGS := -Xlint:all,-deprecation -Werror > +JAVAC_WARNINGS := -Xlint:all -Werror > > # The BOOT_JAVAC setup uses the boot jdk compiler to compile the tools > # and the interim javac, to be run by the boot jdk. > > As usual for this kind of change, a jprt job will be used to verify > the fix is valid on all platforms, etc. > > Thanks, > > -Joe From aph at redhat.com Wed Dec 10 09:08:21 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 10 Dec 2014 09:08:21 +0000 Subject: How to cross compile OpenJDK for Arm32? In-Reply-To: References: Message-ID: <54880D85.3040502@redhat.com> On 10/12/14 03:29, ChenLong wrote: > 2) Is there any place that I can download prebuilt sysroot/rootfs? That would be great helpful. It makes far more sense simply to copy the root filesystem from your target. You really don't want someone else's sysroot. Andrew. From erik.joelsson at oracle.com Wed Dec 10 11:30:56 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Dec 2014 12:30:56 +0100 Subject: RFR: JDK-8067060: build can still fail with spaces following -L on link lines Message-ID: <54882EF0.9090603@oracle.com> Hello, Embarrassingly enough, my last fix for the -L and space problem wasn't correct. Here is a new fix where I'm reverting the macro definitions from using define to simple = assignment. The latter automatically strips leading whitespace and IMO fits better for the type of macro that should not be called with $(eval ). (See bug for more detailed explanation). This time I made sure to grep the build log on a mac for '-L ' to make sure I didn't miss anything. Stuart: could you make sure this patch works since I can't repro the actual failure? Bug: https://bugs.openjdk.java.net/browse/JDK-8067060 Webrev: http://cr.openjdk.java.net/~erikj/8067060/webrev.jdk.01/ /Erik From stuart.marks at oracle.com Thu Dec 11 05:16:11 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 10 Dec 2014 21:16:11 -0800 Subject: RFR: JDK-8067060: build can still fail with spaces following -L on link lines In-Reply-To: <54882EF0.9090603@oracle.com> References: <54882EF0.9090603@oracle.com> Message-ID: <5489289B.4030902@oracle.com> On 12/10/14 3:30 AM, Erik Joelsson wrote: > Stuart: could you make sure this patch works since I can't repro the actual > failure? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067060 > Webrev: http://cr.openjdk.java.net/~erikj/8067060/webrev.jdk.01/ > > /Erik Yup, build works for me with this patch applied. Thanks for cranking it out. s'marks From Alan.Bateman at oracle.com Thu Dec 11 15:07:53 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Dec 2014 15:07:53 +0000 Subject: RFR: JDK-8065673: Makefile enable JAXP tests running In-Reply-To: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com> References: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com> Message-ID: <5489B349.6040009@oracle.com> On 11/12/2014 14:38, Tristan Yan wrote: > Hi everyone > > Could you please to review this small makefile change for JAXP tests > > http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.00/ > http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ > > corresponding bug is https://bugs.openjdk.java.net/browse/JDK-8065673 > > Here is the background for this change. > As you may know we?ve pushed some new jaxp tests into openjdk. Since these tests have been put into different repo with current idk tests. We need a makefile to support these tests running in jprt system and nightly. In the future, we may put these tests back to idk repo, we have to maintain a consistent makefile with current idk tests. So I steal the makefile from idk test repo and make minimal change as possible. > For supporting running tests in jprt system one new target(jaxp_test) has been added in top level makefile and jaxp_test will be considered as part of core testset. > The alternative to adding this to the "core" testset is to create a new testset ("jaxp" or "xml" for example). You could then include this in the "pit" testset so that it runs langtools, core, svc, and jaxp. -Alan From tristan.yan at oracle.com Thu Dec 11 14:38:48 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Thu, 11 Dec 2014 06:38:48 -0800 Subject: RFR: JDK-8065673: Makefile enable JAXP tests running Message-ID: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com> Hi everyone Could you please to review this small makefile change for JAXP tests http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.00/ http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ corresponding bug is https://bugs.openjdk.java.net/browse/JDK-8065673 Here is the background for this change. As you may know we?ve pushed some new jaxp tests into openjdk. Since these tests have been put into different repo with current idk tests. We need a makefile to support these tests running in jprt system and nightly. In the future, we may put these tests back to idk repo, we have to maintain a consistent makefile with current idk tests. So I steal the makefile from idk test repo and make minimal change as possible. For supporting running tests in jprt system one new target(jaxp_test) has been added in top level makefile and jaxp_test will be considered as part of core testset. Thank you very much. Tristan From huizhe.wang at oracle.com Thu Dec 11 17:46:13 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 11 Dec 2014 09:46:13 -0800 Subject: RFR: JDK-8065673: Makefile enable JAXP tests running In-Reply-To: <5489B349.6040009@oracle.com> References: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com> <5489B349.6040009@oracle.com> Message-ID: <5489D865.2060705@oracle.com> On 12/11/2014 7:07 AM, Alan Bateman wrote: > On 11/12/2014 14:38, Tristan Yan wrote: >> Hi everyone >> >> Could you please to review this small makefile change for JAXP tests >> >> http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.00/ >> >> http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ >> >> >> corresponding bug is https://bugs.openjdk.java.net/browse/JDK-8065673 >> >> >> Here is the background for this change. >> As you may know we?ve pushed some new jaxp tests into openjdk. Since >> these tests have been put into different repo with current idk tests. >> We need a makefile to support these tests running in jprt system and >> nightly. In the future, we may put these tests back to idk repo, we >> have to maintain a consistent makefile with current idk tests. So I >> steal the makefile from idk test repo and make minimal change as >> possible. >> For supporting running tests in jprt system one new target(jaxp_test) >> has been added in top level makefile and jaxp_test will be considered >> as part of core testset. >> > The alternative to adding this to the "core" testset is to create a > new testset ("jaxp" or "xml" for example). You could then include this > in the "pit" testset so that it runs langtools, core, svc, and jaxp. Ok, we'll add a new testset "jaxp". -Joe > > -Alan From tristan.yan at oracle.com Thu Dec 11 21:10:03 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Thu, 11 Dec 2014 13:10:03 -0800 Subject: RFR: JDK-8065673: Makefile enable JAXP tests running In-Reply-To: <5489D865.2060705@oracle.com> References: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com> <5489B349.6040009@oracle.com> <5489D865.2060705@oracle.com> Message-ID: <35DC236D-FD79-4D93-AA8C-70390402BE1C@oracle.com> Thanks Alan and Joe I added jaxp testset, now jaxp_tests is under jaxp testset only. Also I have added jaxp testset to pit. http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.01/ http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ Thanks > On Dec 11, 2014, at 9:46 AM, huizhe wang wrote: > > > On 12/11/2014 7:07 AM, Alan Bateman wrote: >> On 11/12/2014 14:38, Tristan Yan wrote: >>> Hi everyone >>> >>> Could you please to review this small makefile change for JAXP tests >>> >>> http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.00/ >>> http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ >>> >>> corresponding bug is https://bugs.openjdk.java.net/browse/JDK-8065673 >>> >>> Here is the background for this change. >>> As you may know we?ve pushed some new jaxp tests into openjdk. Since these tests have been put into different repo with current idk tests. We need a makefile to support these tests running in jprt system and nightly. In the future, we may put these tests back to idk repo, we have to maintain a consistent makefile with current idk tests. So I steal the makefile from idk test repo and make minimal change as possible. >>> For supporting running tests in jprt system one new target(jaxp_test) has been added in top level makefile and jaxp_test will be considered as part of core testset. >>> >> The alternative to adding this to the "core" testset is to create a new testset ("jaxp" or "xml" for example). You could then include this in the "pit" testset so that it runs langtools, core, svc, and jaxp. > > Ok, we'll add a new testset "jaxp". > > -Joe > >> >> -Alan > From Alan.Bateman at oracle.com Fri Dec 12 10:45:16 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Dec 2014 10:45:16 +0000 Subject: RFR: JDK-8065673: Makefile enable JAXP tests running In-Reply-To: <35DC236D-FD79-4D93-AA8C-70390402BE1C@oracle.com> References: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com> <5489B349.6040009@oracle.com> <5489D865.2060705@oracle.com> <35DC236D-FD79-4D93-AA8C-70390402BE1C@oracle.com> Message-ID: <548AC73C.2050805@oracle.com> On 11/12/2014 21:10, Tristan Yan wrote: > Thanks Alan and Joe > I added jaxp testset, now jaxp_tests is under jaxp testset only. Also > I have added jaxp testset to pit. > > http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.01/ > > http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ > > > Thanks > I think this looks much better. A suggestion for the test group name is "jaxp_all" rather than "jaxp_test". A minor comment on jprt.properties is that the comments should probably use "JAXP" rather than "Jaxp". A side question: Are there plans to move the JAXP tests from the jdk/test directory to the jaxp repo so that they can be with their friends? I think that would make this new testset more useful. -Alan. From sgehwolf at redhat.com Fri Dec 12 13:18:45 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 12 Dec 2014 14:18:45 +0100 Subject: RFR(S): 8067330 : ZERO_ARCHDEF incorrectly defined for PPC/PPC64 architectures Message-ID: <1418390325.3181.22.camel@localhost.localdomain> Hi, Could someone please review and sponsor this fix for JDK-8067330? In particular, the hotspot build expects either PPC64 or PPC32 to be defined (hotspot/src/share/vm/utilities/macros.hpp:366) and if one of them is indeed defined PPC gets defined as well. However if neither of the two is defined then PPC gets silently undefined. This may result in incorrectly generated code for the Zero variant build. Bug: https://bugs.openjdk.java.net/browse/JDK-8067330 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8067330/webrev.01/ Thanks! Cheers, Severin From erik.joelsson at oracle.com Fri Dec 12 14:08:22 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 12 Dec 2014 15:08:22 +0100 Subject: RFR: JDK-8067254: No debug symbols in JPRT Windows builds Message-ID: <548AF6D6.7070906@oracle.com> Hello, Please review this fix which returns debug info files to the windows images. In the modular image change I mistakenly filtered out the debug info files (by comparing the new images/jdk/bin dir with the old images/j2sdk-image/bin dir instead of images/j2sdk-image/jre/bin where the files used to be). I also had to patch the jimage build tool to make the .diz, .pdb and .map files end up in the bin dir. Bug: https://bugs.openjdk.java.net/browse/JDK-8067254 Webrev: http://cr.openjdk.java.net/~erikj/8067254/webrev.01/ /Erik From volker.simonis at gmail.com Fri Dec 12 14:12:50 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 12 Dec 2014 15:12:50 +0100 Subject: RFR(S): 8067330 : ZERO_ARCHDEF incorrectly defined for PPC/PPC64 architectures In-Reply-To: <1418390325.3181.22.camel@localhost.localdomain> References: <1418390325.3181.22.camel@localhost.localdomain> Message-ID: Hi Severin, the change looks good to me and it only affects the ZERO build so there's no risk to influene any other platform. Unfortunately I can not push it because it requires the regeneration of 'common/autoconf/generated-configure.sh'. So you still need a sponsor from within Oracle. Regards, Volker On Fri, Dec 12, 2014 at 2:18 PM, Severin Gehwolf wrote: > Hi, > > Could someone please review and sponsor this fix for JDK-8067330? In > particular, the hotspot build expects either PPC64 or PPC32 to be > defined (hotspot/src/share/vm/utilities/macros.hpp:366) and if one of > them is indeed defined PPC gets defined as well. However if neither of > the two is defined then PPC gets silently undefined. This may result in > incorrectly generated code for the Zero variant build. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067330 > webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8067330/webrev.01/ > > Thanks! > > Cheers, > Severin > From tim.bell at oracle.com Fri Dec 12 14:35:04 2014 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 12 Dec 2014 06:35:04 -0800 Subject: RFR: JDK-8067254: No debug symbols in JPRT Windows builds In-Reply-To: <548AF6D6.7070906@oracle.com> References: <548AF6D6.7070906@oracle.com> Message-ID: <548AFD18.1040000@oracle.com> Hi Erik: > Please review this fix which returns debug info files to the windows > images. In the modular image change I mistakenly filtered out the > debug info files (by comparing the new images/jdk/bin dir with the old > images/j2sdk-image/bin dir instead of images/j2sdk-image/jre/bin where > the files used to be). I also had to patch the jimage build tool to > make the .diz, .pdb and .map files end up in the bin dir. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067254 > Webrev: http://cr.openjdk.java.net/~erikj/8067254/webrev.01/ Looks good to me. Tim From erik.joelsson at oracle.com Fri Dec 12 14:31:57 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 12 Dec 2014 15:31:57 +0100 Subject: RFR(S): 8067330 : ZERO_ARCHDEF incorrectly defined for PPC/PPC64 architectures In-Reply-To: References: <1418390325.3181.22.camel@localhost.localdomain> Message-ID: <548AFC5D.6050205@oracle.com> I can push it. /Erik On 2014-12-12 15:12, Volker Simonis wrote: > Hi Severin, > > the change looks good to me and it only affects the ZERO build so > there's no risk to influene any other platform. > > Unfortunately I can not push it because it requires the regeneration > of 'common/autoconf/generated-configure.sh'. So you still need a > sponsor from within Oracle. > > Regards, > Volker > > > On Fri, Dec 12, 2014 at 2:18 PM, Severin Gehwolf wrote: >> Hi, >> >> Could someone please review and sponsor this fix for JDK-8067330? In >> particular, the hotspot build expects either PPC64 or PPC32 to be >> defined (hotspot/src/share/vm/utilities/macros.hpp:366) and if one of >> them is indeed defined PPC gets defined as well. However if neither of >> the two is defined then PPC gets silently undefined. This may result in >> incorrectly generated code for the Zero variant build. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8067330 >> webrev: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8067330/webrev.01/ >> >> Thanks! >> >> Cheers, >> Severin >> From tim.bell at oracle.com Fri Dec 12 14:41:06 2014 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 12 Dec 2014 06:41:06 -0800 Subject: RFR(S): 8067330 : ZERO_ARCHDEF incorrectly defined for PPC/PPC64 architectures In-Reply-To: <548AFC5D.6050205@oracle.com> References: <1418390325.3181.22.camel@localhost.localdomain> <548AFC5D.6050205@oracle.com> Message-ID: <548AFE82.50405@oracle.com> Thanks, Erik The change looks good to me as well. Tim On 12/12/14 06:31, Erik Joelsson wrote: > I can push it. > > /Erik > > On 2014-12-12 15:12, Volker Simonis wrote: >> Hi Severin, >> >> the change looks good to me and it only affects the ZERO build so >> there's no risk to influene any other platform. >> >> Unfortunately I can not push it because it requires the regeneration >> of 'common/autoconf/generated-configure.sh'. So you still need a >> sponsor from within Oracle. >> >> Regards, >> Volker >> >> >> On Fri, Dec 12, 2014 at 2:18 PM, Severin Gehwolf >> wrote: >>> Hi, >>> >>> Could someone please review and sponsor this fix for JDK-8067330? In >>> particular, the hotspot build expects either PPC64 or PPC32 to be >>> defined (hotspot/src/share/vm/utilities/macros.hpp:366) and if one of >>> them is indeed defined PPC gets defined as well. However if neither of >>> the two is defined then PPC gets silently undefined. This may result in >>> incorrectly generated code for the Zero variant build. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067330 >>> webrev: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8067330/webrev.01/ >>> >>> Thanks! >>> >>> Cheers, >>> Severin >>> > From sgehwolf at redhat.com Fri Dec 12 15:08:55 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 12 Dec 2014 16:08:55 +0100 Subject: RFR(S): 8067330 : ZERO_ARCHDEF incorrectly defined for PPC/PPC64 architectures In-Reply-To: <548AFE82.50405@oracle.com> References: <1418390325.3181.22.camel@localhost.localdomain> <548AFC5D.6050205@oracle.com> <548AFE82.50405@oracle.com> Message-ID: <1418396935.3181.63.camel@localhost.localdomain> On Fri, 2014-12-12 at 06:41 -0800, Tim Bell wrote: > Thanks, Erik > > The change looks good to me as well. > > Tim Thanks, all! Cheers, Severin > On 12/12/14 06:31, Erik Joelsson wrote: > > I can push it. > > > > /Erik > > > > On 2014-12-12 15:12, Volker Simonis wrote: > >> Hi Severin, > >> > >> the change looks good to me and it only affects the ZERO build so > >> there's no risk to influene any other platform. > >> > >> Unfortunately I can not push it because it requires the regeneration > >> of 'common/autoconf/generated-configure.sh'. So you still need a > >> sponsor from within Oracle. > >> > >> Regards, > >> Volker > >> > >> > >> On Fri, Dec 12, 2014 at 2:18 PM, Severin Gehwolf > >> wrote: > >>> Hi, > >>> > >>> Could someone please review and sponsor this fix for JDK-8067330? In > >>> particular, the hotspot build expects either PPC64 or PPC32 to be > >>> defined (hotspot/src/share/vm/utilities/macros.hpp:366) and if one of > >>> them is indeed defined PPC gets defined as well. However if neither of > >>> the two is defined then PPC gets silently undefined. This may result in > >>> incorrectly generated code for the Zero variant build. > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067330 > >>> webrev: > >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8067330/webrev.01/ > >>> > >>> Thanks! > >>> > >>> Cheers, > >>> Severin > >>> > > > From huizhe.wang at oracle.com Fri Dec 12 17:45:56 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 12 Dec 2014 09:45:56 -0800 Subject: RFR: JDK-8065673: Makefile enable JAXP tests running In-Reply-To: <548AC73C.2050805@oracle.com> References: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com> <5489B349.6040009@oracle.com> <5489D865.2060705@oracle.com> <35DC236D-FD79-4D93-AA8C-70390402BE1C@oracle.com> <548AC73C.2050805@oracle.com> Message-ID: <548B29D4.6050301@oracle.com> On 12/12/2014 2:45 AM, Alan Bateman wrote: > On 11/12/2014 21:10, Tristan Yan wrote: >> Thanks Alan and Joe >> I added jaxp testset, now jaxp_tests is under jaxp testset only. Also >> I have added jaxp testset to pit. >> >> http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.01/ >> >> http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ >> >> >> Thanks >> > I think this looks much better. A suggestion for the test group name > is "jaxp_all" rather than "jaxp_test". A minor comment on > jprt.properties is that the comments should probably use "JAXP" rather > than "Jaxp". > > A side question: Are there plans to move the JAXP tests from the > jdk/test directory to the jaxp repo so that they can be with their > friends? I think that would make this new testset more useful. Yes, it's in our plan to move jaxp tests from jdk/test to jaxp/test. -Joe > > -Alan. > From tristan.yan at oracle.com Fri Dec 12 18:10:13 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Fri, 12 Dec 2014 10:10:13 -0800 Subject: RFR: JDK-8065673: Makefile enable JAXP tests running In-Reply-To: <548B29D4.6050301@oracle.com> References: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com> <5489B349.6040009@oracle.com> <5489D865.2060705@oracle.com> <35DC236D-FD79-4D93-AA8C-70390402BE1C@oracle.com> <548AC73C.2050805@oracle.com> <548B29D4.6050301@oracle.com> Message-ID: <50BF092B-2F81-42E4-B4F1-64CEC19087A7@oracle.com> Thanks Joe answering this. Updated webrev by changing jaxp_test to jaxp_all, Also correct ?Jaxp" as ?JAXP?. http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.01/ http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.02/ Tristan > On Dec 12, 2014, at 9:45 AM, huizhe wang wrote: > > > On 12/12/2014 2:45 AM, Alan Bateman wrote: >> On 11/12/2014 21:10, Tristan Yan wrote: >>> Thanks Alan and Joe >>> I added jaxp testset, now jaxp_tests is under jaxp testset only. Also I have added jaxp testset to pit. >>> >>> http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.01/ >>> http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ >>> >>> Thanks >>> >> I think this looks much better. A suggestion for the test group name is "jaxp_all" rather than "jaxp_test". A minor comment on jprt.properties is that the comments should probably use "JAXP" rather than "Jaxp". >> >> A side question: Are there plans to move the JAXP tests from the jdk/test directory to the jaxp repo so that they can be with their friends? I think that would make this new testset more useful. > > Yes, it's in our plan to move jaxp tests from jdk/test to jaxp/test. > > -Joe > >> >> -Alan. >> > From mandy.chung at oracle.com Fri Dec 12 18:25:52 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 12 Dec 2014 10:25:52 -0800 Subject: Review request: JDK-8067360: verify-modules target was dropped in jdk9 b41 Message-ID: <548B3330.3050104@oracle.com> Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8067360/webrev.00/ This patch adds back the verify-modules target to the dependences of the images target that got dropped in the merge and hides a bug in jdeps -Xverify:access. Erik - I notice make/Javadoc.gmk that sets -bootclasspath $(JDK_OUTPUTDIR)/classes that does not exist. I include a patch to make/Javadoc.gmk in the webrev. Do you prefer to separate it and file a new bug for it? Mandy From Alan.Bateman at oracle.com Sat Dec 13 10:23:13 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 13 Dec 2014 10:23:13 +0000 Subject: RFR: JDK-8065673: Makefile enable JAXP tests running In-Reply-To: <50BF092B-2F81-42E4-B4F1-64CEC19087A7@oracle.com> References: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com> <5489B349.6040009@oracle.com> <5489D865.2060705@oracle.com> <35DC236D-FD79-4D93-AA8C-70390402BE1C@oracle.com> <548AC73C.2050805@oracle.com> <548B29D4.6050301@oracle.com> <50BF092B-2F81-42E4-B4F1-64CEC19087A7@oracle.com> Message-ID: <548C1391.9030008@oracle.com> On 12/12/2014 18:10, Tristan Yan wrote: > Thanks Joe answering this. > Updated webrev by changing jaxp_test to jaxp_all, Also correct ?Jaxp" > as ?JAXP?. > > http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.01/ > > http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.02/ > > > Given Joe's comment about moving the JAXP tests in the jdk repo then the updated changes look good to me. -Alan. From Alan.Bateman at oracle.com Sat Dec 13 10:25:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 13 Dec 2014 10:25:02 +0000 Subject: Review request: JDK-8067360: verify-modules target was dropped in jdk9 b41 In-Reply-To: <548B3330.3050104@oracle.com> References: <548B3330.3050104@oracle.com> Message-ID: <548C13FE.7080808@oracle.com> On 12/12/2014 18:25, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8067360/webrev.00/ > > This patch adds back the verify-modules target to the dependences of > the images target that got dropped in the merge and hides a bug in > jdeps -Xverify:access. > > Erik - I notice make/Javadoc.gmk that sets -bootclasspath > $(JDK_OUTPUTDIR)/classes that does not exist. I include a patch to > make/Javadoc.gmk in the webrev. Do you prefer to separate it and file > a new bug for it? The fix to jdeps and the re-enabling of verify-modules looks good to me. I'll leave it to Erik and the build folks to comment on the removing of -bootclasspath, it might be clearer to track that separately. -Alan From david.holmes at oracle.com Sat Dec 13 22:52:13 2014 From: david.holmes at oracle.com (David Holmes) Date: Sun, 14 Dec 2014 08:52:13 +1000 Subject: RFR: JDK-8067254: No debug symbols in JPRT Windows builds In-Reply-To: <548AF6D6.7070906@oracle.com> References: <548AF6D6.7070906@oracle.com> Message-ID: <548CC31D.6010302@oracle.com> Hi Erik, Looks okay to me too. David On 13/12/2014 12:08 AM, Erik Joelsson wrote: > Hello, > > Please review this fix which returns debug info files to the windows > images. In the modular image change I mistakenly filtered out the debug > info files (by comparing the new images/jdk/bin dir with the old > images/j2sdk-image/bin dir instead of images/j2sdk-image/jre/bin where > the files used to be). I also had to patch the jimage build tool to make > the .diz, .pdb and .map files end up in the bin dir. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067254 > Webrev: http://cr.openjdk.java.net/~erikj/8067254/webrev.01/ > > /Erik > From magnus.ihse.bursie at oracle.com Sun Dec 14 20:46:39 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sun, 14 Dec 2014 21:46:39 +0100 Subject: RFR: JDK-8067254: No debug symbols in JPRT Windows builds In-Reply-To: <548AF6D6.7070906@oracle.com> References: <548AF6D6.7070906@oracle.com> Message-ID: Desto st?rre sk?l att inte kolla extension i ImageBuilder/jlink utan ha en separat flagga f?r s?nt som ska till bin p? Windows och lib i resten av v?rlden. /Magnus > 12 dec 2014 kl. 15:08 skrev Erik Joelsson : > > Hello, > > Please review this fix which returns debug info files to the windows images. In the modular image change I mistakenly filtered out the debug info files (by comparing the new images/jdk/bin dir with the old images/j2sdk-image/bin dir instead of images/j2sdk-image/jre/bin where the files used to be). I also had to patch the jimage build tool to make the .diz, .pdb and .map files end up in the bin dir. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067254 > Webrev: http://cr.openjdk.java.net/~erikj/8067254/webrev.01/ > > /Erik > From tim.bell at oracle.com Sun Dec 14 22:12:54 2014 From: tim.bell at oracle.com (Tim Bell) Date: Sun, 14 Dec 2014 14:12:54 -0800 Subject: RFR: JDK-8067254: No debug symbols in JPRT Windows builds In-Reply-To: References: <548AF6D6.7070906@oracle.com> Message-ID: <548E0B66.6000203@oracle.com> Agreed or ?verens according to google translate :-) Tim On 12/14/14 12:46, Magnus Ihse Bursie wrote: > Desto st?rre sk?l att inte kolla extension i ImageBuilder/jlink utan ha en separat flagga f?r s?nt som ska till bin p? Windows och lib i resten av v?rlden. > > /Magnus > >> 12 dec 2014 kl. 15:08 skrev Erik Joelsson: >> >> Hello, >> >> Please review this fix which returns debug info files to the windows images. In the modular image change I mistakenly filtered out the debug info files (by comparing the new images/jdk/bin dir with the old images/j2sdk-image/bin dir instead of images/j2sdk-image/jre/bin where the files used to be). I also had to patch the jimage build tool to make the .diz, .pdb and .map files end up in the bin dir. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8067254 >> Webrev: http://cr.openjdk.java.net/~erikj/8067254/webrev.01/ >> >> /Erik >> From erik.joelsson at oracle.com Mon Dec 15 08:56:11 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 15 Dec 2014 09:56:11 +0100 Subject: Review request: JDK-8067360: verify-modules target was dropped in jdk9 b41 In-Reply-To: <548B3330.3050104@oracle.com> References: <548B3330.3050104@oracle.com> Message-ID: <548EA22B.309@oracle.com> Looks good to me. I don't mind if you fix javadoc in the same change. It's such a small issue I rather not go through the hassle of creating a bug and a new review. Thanks! /Erik On 2014-12-12 19:25, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8067360/webrev.00/ > > This patch adds back the verify-modules target to the dependences of > the images target that got dropped in the merge and hides a bug in > jdeps -Xverify:access. > > Erik - I notice make/Javadoc.gmk that sets -bootclasspath > $(JDK_OUTPUTDIR)/classes that does not exist. I include a patch to > make/Javadoc.gmk in the webrev. Do you prefer to separate it and file > a new bug for it? > > Mandy > > From erik.joelsson at oracle.com Mon Dec 15 09:24:57 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 15 Dec 2014 10:24:57 +0100 Subject: RFR: 8066138: Trailing whitespace in title of javadoc In-Reply-To: <20141128110633.GA9294@e6430> References: <20141128110633.GA9294@e6430> Message-ID: <548EA8E9.6040202@oracle.com> Change looks good to me. /Erik On 2014-11-28 12:06, Andreas Lundblad wrote: > Hi build-dev, > > Would appreciate a review of this small patch that addresses JDK-8066138. > > The patch removes trailing whitespace in javadoc titles such as "Overview (Java Platform SE 7 )" > > Link to webrev: > http://cr.openjdk.java.net/~alundblad/8066138/ > > Link to bug report: > https://bugs.openjdk.java.net/browse/JDK-8066138 > > thanks in advance, > Andreas Lundblad From erik.helin at oracle.com Mon Dec 15 15:20:47 2014 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 15 Dec 2014 16:20:47 +0100 Subject: 8067442: Tests using -Xshare:dump does not work with 'make test' Message-ID: <20141215152047.GC24542@ehelin.jrpg.bea.com> Hi all, this patch changes the dependency for the target `test` in make/Main.gmk from exploded-image to jimages. This is needed because PRODUCT_HOME in `make test` needs to be set to a full JDK image directory, because there are tests in hotspot/test that uses -Xshare:dump and -Xshare:dump does not work with an exploded jdk image. There are currently 9 tests that are failing due to this when running: $ make test TEST=hotspot_runtime Webrev: http://cr.openjdk.java.net/~ehelin/8067442/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8067442 Testing: - Run `make test TEST=hotspot_runtime` on Linux x86-64 and verified that all tests now passes. Thanks, Erik From erik.joelsson at oracle.com Mon Dec 15 15:35:11 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 15 Dec 2014 16:35:11 +0100 Subject: 8067442: Tests using -Xshare:dump does not work with 'make test' In-Reply-To: <20141215152047.GC24542@ehelin.jrpg.bea.com> References: <20141215152047.GC24542@ehelin.jrpg.bea.com> Message-ID: <548EFFAF.5010209@oracle.com> Hello, Change looks good to me. Note that the dependencies used to be on images, but I recently changed this to the exploded images thinking that it would be more convenient and that most tests would work anyway (or at least those that people wanted to run). Since that is not the case, I support changing it back. /Erik On 2014-12-15 16:20, Erik Helin wrote: > Hi all, > > this patch changes the dependency for the target `test` in make/Main.gmk > from exploded-image to jimages. This is needed because PRODUCT_HOME in > `make test` needs to be set to a full JDK image directory, because there > are tests in hotspot/test that uses -Xshare:dump and -Xshare:dump does > not work with an exploded jdk image. > > There are currently 9 tests that are failing due to this when running: > $ make test TEST=hotspot_runtime > > Webrev: > http://cr.openjdk.java.net/~ehelin/8067442/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8067442 > > Testing: > - Run `make test TEST=hotspot_runtime` on Linux x86-64 and verified > that all tests now passes. > > Thanks, > Erik From mandy.chung at oracle.com Mon Dec 15 18:38:44 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 15 Dec 2014 10:38:44 -0800 Subject: Review request: JDK-8067360: verify-modules target was dropped in jdk9 b41 In-Reply-To: <548EA22B.309@oracle.com> References: <548B3330.3050104@oracle.com> <548EA22B.309@oracle.com> Message-ID: <548F2AB4.10507@oracle.com> Thanks for the review. I don't mind filing a bug for javadoc change and it's easy as it's a separate issue and cleaner to separate them. I'm happy this saves me the hassle of a separate review, thanks! Mandy On 12/15/14 12:56 AM, Erik Joelsson wrote: > Looks good to me. I don't mind if you fix javadoc in the same change. > It's such a small issue I rather not go through the hassle of creating > a bug and a new review. > > Thanks! > /Erik > > On 2014-12-12 19:25, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8067360/webrev.00/ >> >> This patch adds back the verify-modules target to the dependences of >> the images target that got dropped in the merge and hides a bug in >> jdeps -Xverify:access. >> >> Erik - I notice make/Javadoc.gmk that sets -bootclasspath >> $(JDK_OUTPUTDIR)/classes that does not exist. I include a patch to >> make/Javadoc.gmk in the webrev. Do you prefer to separate it and >> file a new bug for it? >> >> Mandy >> >> > From david.holmes at oracle.com Tue Dec 16 05:23:51 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Dec 2014 15:23:51 +1000 Subject: 8067442: Tests using -Xshare:dump does not work with 'make test' In-Reply-To: <20141215152047.GC24542@ehelin.jrpg.bea.com> References: <20141215152047.GC24542@ehelin.jrpg.bea.com> Message-ID: <548FC1E7.4020308@oracle.com> On 16/12/2014 1:20 AM, Erik Helin wrote: > Hi all, > > this patch changes the dependency for the target `test` in make/Main.gmk > from exploded-image to jimages. This is needed because PRODUCT_HOME in > `make test` needs to be set to a full JDK image directory, because there > are tests in hotspot/test that uses -Xshare:dump and -Xshare:dump does > not work with an exploded jdk image. Is that something that should be fixed? What you are doing now seems a temporary workaround. David > There are currently 9 tests that are failing due to this when running: > $ make test TEST=hotspot_runtime > > Webrev: > http://cr.openjdk.java.net/~ehelin/8067442/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8067442 > > Testing: > - Run `make test TEST=hotspot_runtime` on Linux x86-64 and verified > that all tests now passes. > > Thanks, > Erik > From erik.helin at oracle.com Tue Dec 16 09:50:35 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 16 Dec 2014 10:50:35 +0100 Subject: 8067442: Tests using -Xshare:dump does not work with 'make test' In-Reply-To: <548FC1E7.4020308@oracle.com> References: <20141215152047.GC24542@ehelin.jrpg.bea.com> <548FC1E7.4020308@oracle.com> Message-ID: <20141216095035.GC3493@ehelin.jrpg.bea.com> On 2014-12-16, David Holmes wrote: > On 16/12/2014 1:20 AM, Erik Helin wrote: > >Hi all, > > > >this patch changes the dependency for the target `test` in make/Main.gmk > >from exploded-image to jimages. This is needed because PRODUCT_HOME in > >`make test` needs to be set to a full JDK image directory, because there > >are tests in hotspot/test that uses -Xshare:dump and -Xshare:dump does > >not work with an exploded jdk image. > > Is that something that should be fixed? What you are doing now seems a > temporary workaround. I am not familiar with the class data sharing (CDS) implementation, but the failures all give the same error: Hint: enable -XX:+TraceClassPaths to diagnose the failure Error occurred during initialization of VM CDS allows only empty directories in archived classpaths I don't know why CDS does not allow non-empty directories on the archived classpath, maybe Ioi can answer that? Anyhow, I believe that eventually enhancing CDS to allow non-empty directories on the archived classpath is a separate patch. This patch is about reversing the change that Erik did (see his reply for more details) to make sure that we can run the tests. What do you think? Thanks, Erik > David > > >There are currently 9 tests that are failing due to this when running: > >$ make test TEST=hotspot_runtime > > > >Webrev: > >http://cr.openjdk.java.net/~ehelin/8067442/webrev.00/ > > > >Bug: > >https://bugs.openjdk.java.net/browse/JDK-8067442 > > > >Testing: > >- Run `make test TEST=hotspot_runtime` on Linux x86-64 and verified > > that all tests now passes. > > > >Thanks, > >Erik > > From david.holmes at oracle.com Tue Dec 16 09:59:16 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Dec 2014 19:59:16 +1000 Subject: 8067442: Tests using -Xshare:dump does not work with 'make test' In-Reply-To: <20141216095035.GC3493@ehelin.jrpg.bea.com> References: <20141215152047.GC24542@ehelin.jrpg.bea.com> <548FC1E7.4020308@oracle.com> <20141216095035.GC3493@ehelin.jrpg.bea.com> Message-ID: <54900274.8040908@oracle.com> On 16/12/2014 7:50 PM, Erik Helin wrote: > On 2014-12-16, David Holmes wrote: >> On 16/12/2014 1:20 AM, Erik Helin wrote: >>> Hi all, >>> >>> this patch changes the dependency for the target `test` in make/Main.gmk >> >from exploded-image to jimages. This is needed because PRODUCT_HOME in >>> `make test` needs to be set to a full JDK image directory, because there >>> are tests in hotspot/test that uses -Xshare:dump and -Xshare:dump does >>> not work with an exploded jdk image. >> >> Is that something that should be fixed? What you are doing now seems a >> temporary workaround. > > I am not familiar with the class data sharing (CDS) implementation, but > the failures all give the same error: > > Hint: enable -XX:+TraceClassPaths to diagnose the failure > Error occurred during initialization of VM > CDS allows only empty directories in archived classpaths > > I don't know why CDS does not allow non-empty directories on the > archived classpath, maybe Ioi can answer that? It is because the classpath has ot be known to be the same at dump time and runtime. If we allowed directories in the classpath (versus jars) then we would have to track the directory contents. > Anyhow, I believe that eventually enhancing CDS to allow non-empty > directories on the archived classpath is a separate patch. This patch is > about reversing the change that Erik did (see his reply for more > details) to make sure that we can run the tests. > > What do you think? Yes that is fine. I think these tests would also have failed in the non-modular image if run against the jdk directory rather than the image. Thanks, David > > Thanks, > Erik > >> David >> >>> There are currently 9 tests that are failing due to this when running: >>> $ make test TEST=hotspot_runtime >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8067442/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8067442 >>> >>> Testing: >>> - Run `make test TEST=hotspot_runtime` on Linux x86-64 and verified >>> that all tests now passes. >>> >>> Thanks, >>> Erik >>> From magnus.ihse.bursie at oracle.com Tue Dec 16 13:59:04 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 16 Dec 2014 14:59:04 +0100 Subject: RFR: JDK-8067254: No debug symbols in JPRT Windows builds In-Reply-To: <548E0B66.6000203@oracle.com> References: <548AF6D6.7070906@oracle.com> <548E0B66.6000203@oracle.com> Message-ID: Sorry about that. It was supposed to be a private reply to Erik only, but I hit "reply all" by mistake. /Magnus > 14 dec 2014 kl. 23:12 skrev Tim Bell : > > Agreed or ?verens according to google translate :-) > > Tim > > >> On 12/14/14 12:46, Magnus Ihse Bursie wrote: >> Desto st?rre sk?l att inte kolla extension i ImageBuilder/jlink utan ha en separat flagga f?r s?nt som ska till bin p? Windows och lib i resten av v?rlden. >> >> /Magnus >> >>> 12 dec 2014 kl. 15:08 skrev Erik Joelsson: >>> >>> Hello, >>> >>> Please review this fix which returns debug info files to the windows images. In the modular image change I mistakenly filtered out the debug info files (by comparing the new images/jdk/bin dir with the old images/j2sdk-image/bin dir instead of images/j2sdk-image/jre/bin where the files used to be). I also had to patch the jimage build tool to make the .diz, .pdb and .map files end up in the bin dir. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067254 >>> Webrev: http://cr.openjdk.java.net/~erikj/8067254/webrev.01/ >>> >>> /Erik >>> > From stuart.marks at oracle.com Tue Dec 16 17:38:16 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 16 Dec 2014 09:38:16 -0800 Subject: RFR(s): 8067631: hgforest.sh mishandles arguments with spaces Message-ID: <54906E08.7060200@oracle.com> Hi all, Please review this change to hgforest.sh, to preserve argument quoting when passing arguments with spaces through to the hg command. Changeset (in the new sandbox repo): http://hg.openjdk.java.net/jdk9/sandbox/rev/886037762070 Bug: https://bugs.openjdk.java.net/browse/JDK-8067631 Thanks, s'marks From chris.hegarty at oracle.com Tue Dec 16 17:58:12 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 16 Dec 2014 17:58:12 +0000 Subject: RFR(s): 8067631: hgforest.sh mishandles arguments with spaces In-Reply-To: <54906E08.7060200@oracle.com> References: <54906E08.7060200@oracle.com> Message-ID: <660BD8D5-3ECB-4256-9953-90D3C0B148F4@oracle.com> Looks good to me Stuart. I tried the patch on Mac and Linux, both with the OpenJDK set of repos and with Oracle?s additional ones, and all seems ok. -Chris. On 16 Dec 2014, at 17:38, Stuart Marks wrote: > Hi all, > > Please review this change to hgforest.sh, to preserve argument quoting when passing arguments with spaces through to the hg command. > > Changeset (in the new sandbox repo): > > http://hg.openjdk.java.net/jdk9/sandbox/rev/886037762070 > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8067631 > > Thanks, > > s'marks From stuart.marks at oracle.com Tue Dec 16 22:01:39 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 16 Dec 2014 14:01:39 -0800 Subject: RFR(s): 8067631: hgforest.sh mishandles arguments with spaces In-Reply-To: <660BD8D5-3ECB-4256-9953-90D3C0B148F4@oracle.com> References: <54906E08.7060200@oracle.com> <660BD8D5-3ECB-4256-9953-90D3C0B148F4@oracle.com> Message-ID: <5490ABC3.3080903@oracle.com> Hi Chris, thanks for the extra testing. s'marks On 12/16/14 9:58 AM, Chris Hegarty wrote: > Looks good to me Stuart. > > I tried the patch on Mac and Linux, both with the OpenJDK set of repos and with Oracle?s additional ones, and all seems ok. > > -Chris. > > On 16 Dec 2014, at 17:38, Stuart Marks wrote: > >> Hi all, >> >> Please review this change to hgforest.sh, to preserve argument quoting when passing arguments with spaces through to the hg command. >> >> Changeset (in the new sandbox repo): >> >> http://hg.openjdk.java.net/jdk9/sandbox/rev/886037762070 >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8067631 >> >> Thanks, >> >> s'marks > From cedric.champeau at gmail.com Fri Dec 19 09:08:45 2014 From: cedric.champeau at gmail.com (=?UTF-8?B?Q8OpZHJpYyBDaGFtcGVhdQ==?=) Date: Fri, 19 Dec 2014 10:08:45 +0100 Subject: Problem building JDK 8 Message-ID: <5493EB1D.2010405@gmail.com> Hi everyone, Some of you may know that we try to test Groovy builds against the latest versions of the JDK. For that, we have setup a CI build of OpenJDK 7, 8 and 9. However, the JDK 8 builds have been failing for several months now (sorry I didn't have much time to investigate this specific subject, so I rely on EA builds instead, which gives us late but valuable feedback). Basically, in the JDK 8 build log (JDK 9 doesn't have the issue), I can read this in the logs: [02:00:17]: [Step 1/2] configure: error: Could not find freetype! You might be able to fix this by running 'sudo apt-get install libfreetype6-dev'. However if I try to do so, I see that freetype *is* installed: # apt-get install libfreetype6-dev Reading package lists... Done Building dependency tree Reading state information... Done libfreetype6-dev is already the newest version. The server is running Ubuntu 14.04.1 LTS, which gcc 4.8.2, which is supposed to "work flawlessly" from what I read here: https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms We build from http://hg.openjdk.java.net/jdk8u/jdk8u Thanks for your help! -- C?dric Champeau SpringSource - Pivotal http://twitter.com/CedricChampeau http://melix.github.io/blog http://spring.io/ http://www.gopivotal.com/ From martinrb at google.com Fri Dec 19 22:21:02 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 19 Dec 2014 14:21:02 -0800 Subject: Problem building JDK 8 In-Reply-To: <5493EB1D.2010405@gmail.com> References: <5493EB1D.2010405@gmail.com> Message-ID: Others don't seem to have this problem - you can try looking at config.log and elsewhere trying to figure out what went wrong. On Fri, Dec 19, 2014 at 1:08 AM, C?dric Champeau wrote: > Hi everyone, > > Some of you may know that we try to test Groovy builds against the latest > versions of the JDK. For that, we have setup a CI build of OpenJDK 7, 8 and > 9. However, the JDK 8 builds have been failing for several months now (sorry > I didn't have much time to investigate this specific subject, so I rely on > EA builds instead, which gives us late but valuable feedback). > > Basically, in the JDK 8 build log (JDK 9 doesn't have the issue), I can read > this in the logs: > > [02:00:17]: [Step 1/2] configure: error: Could not find freetype! You > might be able to fix this by running 'sudo apt-get install > libfreetype6-dev'. > > However if I try to do so, I see that freetype *is* installed: > > # apt-get install libfreetype6-dev > Reading package lists... Done > Building dependency tree > Reading state information... Done > libfreetype6-dev is already the newest version. > > The server is running Ubuntu 14.04.1 LTS, which gcc 4.8.2, which is supposed > to "work flawlessly" from what I read here: > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > We build from http://hg.openjdk.java.net/jdk8u/jdk8u > > Thanks for your help! > > -- > C?dric Champeau > SpringSource - Pivotal > http://twitter.com/CedricChampeau > http://melix.github.io/blog > http://spring.io/ http://www.gopivotal.com/ > From Sergey.Bylokhov at oracle.com Mon Dec 29 12:22:31 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 29 Dec 2014 15:22:31 +0300 Subject: [9] Review Request: 8056214 Stop including libjawt in libawt_xawt Message-ID: <54A14787.6040603@oracle.com> Hello. Please review the fix for jdk 9. libjawt was removed from the libawt_xawt. See bug report for additional information. Bug: https://bugs.openjdk.java.net/browse/JDK-8056214 Webrev can be found at: http://cr.openjdk.java.net/~serb/8056214/webrev.00 -- Best regards, Sergey. From tim.bell at oracle.com Mon Dec 29 20:06:52 2014 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 29 Dec 2014 12:06:52 -0800 Subject: [9] Review Request: 8056214 Stop including libjawt in libawt_xawt In-Reply-To: <54A14787.6040603@oracle.com> References: <54A14787.6040603@oracle.com> Message-ID: <54A1B45C.1060409@oracle.com> On 12/29/14 04:22, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > libjawt was removed from the libawt_xawt. See bug report for > additional information. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8056214 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8056214/webrev.00 > Looks good to me. Happy holidays - not sure how many others are around at the moment. Tim From anton.tarasov at oracle.com Tue Dec 30 13:28:20 2014 From: anton.tarasov at oracle.com (Anton Tarasov) Date: Tue, 30 Dec 2014 16:28:20 +0300 Subject: [9] Review Request: 8056214 Stop including libjawt in libawt_xawt In-Reply-To: <54A14787.6040603@oracle.com> References: <54A14787.6040603@oracle.com> Message-ID: <54A2A874.6070706@oracle.com> Hi Sergey, This looks reasonable to me. Regards Anton. On 29/12/14 15:22, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > libjawt was removed from the libawt_xawt. See bug report for > additional information. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8056214 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8056214/webrev.00 > From cmetcalf at ezchip.com Tue Dec 30 21:16:03 2014 From: cmetcalf at ezchip.com (Chris Metcalf) Date: Tue, 30 Dec 2014 16:16:03 -0500 Subject: Fix currency-related build failure starting 12/31/2014 Message-ID: <54A31613.4000905@ezchip.com> Our JDK 1.6 and 1.7 builds began failing today with the message "Error: time is more than 10 years from present: 1104530400000". At midnight Turkish time on Dec 31, 2004, the new Turkish lira (TRY) replaced the old lira (TRL) at 1,000,000:1. You may note that this was exactly 10 years ago today. Some enterprising long-ago coder included a sanity test that all currency conversions happen within 10 years of the current moment, but clearly they must have meant "no more than 10 years into the future". To correct this, I remove the Math.abs() from the code in question. I admit to not being familiar with the bug submission and patch submission process for OpenJDK, but hopefully as a trivial fix there is no issue with copyright assignment or other technicalities. I just submit this in hope that it avoids more folks wasting their time on this issue. --- openjdk/jdk/make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java 2014-12-30 20:49:40.000000000 -0500 +++ openjdk/jdk/make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java 2014-12-30 20:49:40.000000000 -0500 @@ -281,7 +281,7 @@ checkCurrencyCode(newCurrency); String timeString = currencyInfo.substring(4, length - 4); long time = format.parse(timeString).getTime(); - if (Math.abs(time - System.currentTimeMillis()) > ((long) 10) * 365 * 24 * 60 * 60 * 1000) { + if (time - System.currentTimeMillis() > ((long) 10) * 365 * 24 * 60 * 60 * 1000) { throw new RuntimeException("time is more than 10 years from present: " + time); } specialCaseCutOverTimes[specialCaseCount] = time; -- Chris Metcalf, EZChip Semiconductor http://www.ezchip.com