Re: Ho to create stable cygwin build environment.
Hi Moshe, I think this has been pointed out before: https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms You're building 8u on a newer Windows and with a newer VisualStudio. I expect the VS version is more an issue than the Windows version, but then Windows 10 does have some quirks. Sorry I can't offer any specific help. David On 30/07/2019 3:11 am, Moshe Zuisman wrote: Hi all. I still face a problem building last j*dk8u source at my windows 10 maachine* *sh C:\openJdk8u_test\jdk8u\hotspot/make/windows/build_vm_def.sh C:\progra~2\micros~1\2017\profes~1\vc\tools\msvc\1416~1.270\bin\hostx86\x64\link.exe @C:\cygwin64\tmp\nmE8BD.tmp Creating library jvm.lib and object jvm.expad_x86_64_peephole.obj : error LNK2011: precompiled object not linked in; image may not runjvm.dll : fatal error LNK1120: 1 unresolved externalsNMAKE : fatal error U1077: 'C:\progra~2\micros~1\2017\profes~1\vc\tools\msvc\1416~1.270\bin\hostx86\x64\link.exe' : return code '0x460'Stop.NMAKE : fatal error U1077: 'cd' : return code '0x2'Stop.NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1\2017\PROFES~1\VC\Tools\MSVC\14.16.27023\bin\HostX86\x86\nmake.EXE' : return code '0x2'Stop.make[3]: *** [Makefile:231: generic_build2] Error 2make[2]: *** [Makefile:177: product] Error 2make[1]: *** [HotspotWrapper.gmk:45: /cygdrive/c/openJdk8u_test/jdk8u/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2make: *** [/cygdrive/c/openJdk8u_test/jdk8u//make/Main.gmk:110: hotspot-only] Error 2* But - if to define it more general. Is there some general, reproducable procedure of creating working build environment at windows?, Like: - minimal version of Windows - minimal version of Visual C and list of its required components and their minimal versions - minimal version of cygwin. Since except obvious problem, that I do not sucess to get working build of JDK (while 3 months ago with then last source - it worked), there is another problem that I do not success to understand. At 2 machines with same version of VC and same version of cygwin (actually - I copied it from one machine to another) I get different errors at build... And this is something - totally beyond my understanding...
Re: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u
On 7/29/19 7:37 PM, Severin Gehwolf wrote: > So, in light of the changed build system in JDK 9+, and the rather > small changes in this patch (on the grand scheme of things), it seems > reasonable to implement this feature in the way proposed. It's a JDK 8u > *enhancement* after all. I am with Severin here. The lack of acceptance test profile in 8u is severely impeding 8u backporting work. I personally keep Severin's patches applied at all times in my local patch queue, because that is the only way I can have 8u coverage more or less similar to what I do for 11u backports. Langtools build changes do not look bad, and they are pretty isolated from the rest of build system, which means we are not risking regressing important stuff. -- Thanks, -Aleksey
Re: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u
On Mon, 2019-07-29 at 16:32 +0100, Andrew John Hughes wrote: > > On 29/07/2019 11:10, Severin Gehwolf wrote: > > On Mon, 2019-07-29 at 10:19 +0100, Andrew Dinn wrote: > > > On 26/07/2019 18:32, Andrew John Hughes wrote: > > > > On 26/07/2019 16:53, Severin Gehwolf wrote: > > [...] > > > > > > What exactly is being pushed > > > > > > here? > > > > > > > > > > The following 4 patches: > > > > > > > > > > jdk: > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ > > > > > hotspot: > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/ > > > > > langtools: > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/langtools/webrev/ > > > > > top: > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/ > > > > > > > > > > Each of them has a reference to a plain patch file if you prefer to > > > > > review that. > > > > > > > > > > Thanks, > > > > > Severin > > > > > > > > > > > > > Ok. HotSpot, JDK & top look fine, but there seem to be a lot of changes > > > > in langtools. Are these original changes to this patch or are they > > > > backports? Is there a reason langtools needs so much more work than the > > > > others? > > > The langtools Makefile changes appear to be larger because they required > > > adding a load of definitions/macros that are already present in the > > > Makefiles in the other trees (i.e. AWK, CAT etc, ZIP_UP_RESULTS, > > > BUNDLE_UP_AND_EXIT etc). These changes look ok to me. > > > > Yes, exactly. The langools Makefile looks *very* different from > > jdk/hotspot. In order to get some unified status of test results across > > all three, these changes were needed. I've opted to make the langools > > Makefile look more like the ones from jdk and hotspot. > > > > Old "make test" from top-level continues to work with these changes > > (modulo -verbose:nopass=> summary change). > > > > Anyway, I had another look at this and made 8075546[1] another pre- > > requisite which makes the langtools changes slightly smaller. Updated > > webrevs set, thus, is: > > > > jdk: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ > > hotspot: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/ > > langtools: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/05/langtools/webrev/ > > top: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/ > > > > Thanks, > > Severin > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8075546 > > > > Right. That doesn't answer the question as to the origin of the changes. > If I look at the langtools Makefile in OpenJDK 11, it doesn't have these > changes. Should they not go there first if they are needed? It looks like test/langtools/Makefile in JDK 11 is not used. At least make run-test-tier1 doesn't use it in JDK 11. I've just tried the following which works fine: $ rm test/langtools/Makefile $ hg status R test/langtools/Makefile $ make JAVAC_FLAGS=-g DISABLE_INTREE_EC=true LOG=debug run-test-tier1 Old make files have been removed with JDK-8217638 in JDK 13. To answer your question: I don't think these changes are needed for OpenJDK 11 as it has the "run-tests" facility (JDK-8176084) which deprecates the old way of running tests. Having said that, it seems more intrusive to try to get that facility ported to JDK 8u, than proceeding with the proposed change. JDK-8217638 suggests that old make files were kept for preserving some old workflows. Due to deprecation of "make test" from JDK 8 in JDK 9+, most of it is different from JDK 9+ onwards. For some time, both approaches seem to have kept working. I'm not sure in what way "make run-test" depends on the new build system in JDK 9. It may do. Briefly looking at the run-test patches it seems to open a can of worms. Incidentally, JDK-8170629, as one of the changes to the build/test infrastructure which happened in JDK 9 timeframe, seems to confirm that langtools is the "odd-man-out" in terms of make files and code duplication :) > Update releases are primarily for backports, so I'm dubious of anything > that brings in a bunch of apparently new changes without making it clear > why there are needed and why a backport is not appropriate. I realize that. There is a balance to strike, though. Backports-only vs. small enhancements. Considering that OpenJDK 8u will go on for some time to come it seems beneficial to have some way for developers of running a known-to-be-working set of tests. That's going to be the bar which every new contribution will have to pass. Current facility only runs jdk and langtools tests, does not print a summary, doesn't work well in CI environments, etc. The proposal preserves the old functionality, but also allows for a new "tier1" target. So, in light of the changed build system in JDK 9+, and the rather small changes in this patch (on the grand scheme of
Ho to create stable cygwin build environment.
Hi all. I still face a problem building last j*dk8u source at my windows 10 maachine* *sh C:\openJdk8u_test\jdk8u\hotspot/make/windows/build_vm_def.sh C:\progra~2\micros~1\2017\profes~1\vc\tools\msvc\1416~1.270\bin\hostx86\x64\link.exe @C:\cygwin64\tmp\nmE8BD.tmp Creating library jvm.lib and object jvm.expad_x86_64_peephole.obj : error LNK2011: precompiled object not linked in; image may not runjvm.dll : fatal error LNK1120: 1 unresolved externalsNMAKE : fatal error U1077: 'C:\progra~2\micros~1\2017\profes~1\vc\tools\msvc\1416~1.270\bin\hostx86\x64\link.exe' : return code '0x460'Stop.NMAKE : fatal error U1077: 'cd' : return code '0x2'Stop.NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1\2017\PROFES~1\VC\Tools\MSVC\14.16.27023\bin\HostX86\x86\nmake.EXE' : return code '0x2'Stop.make[3]: *** [Makefile:231: generic_build2] Error 2make[2]: *** [Makefile:177: product] Error 2make[1]: *** [HotspotWrapper.gmk:45: /cygdrive/c/openJdk8u_test/jdk8u/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2make: *** [/cygdrive/c/openJdk8u_test/jdk8u//make/Main.gmk:110: hotspot-only] Error 2* But - if to define it more general. Is there some general, reproducable procedure of creating working build environment at windows?, Like: - minimal version of Windows - minimal version of Visual C and list of its required components and their minimal versions - minimal version of cygwin. Since except obvious problem, that I do not sucess to get working build of JDK (while 3 months ago with then last source - it worked), there is another problem that I do not success to understand. At 2 machines with same version of VC and same version of cygwin (actually - I copied it from one machine to another) I get different errors at build... And this is something - totally beyond my understanding...
Re: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u
On 29/07/2019 11:10, Severin Gehwolf wrote: > On Mon, 2019-07-29 at 10:19 +0100, Andrew Dinn wrote: >> On 26/07/2019 18:32, Andrew John Hughes wrote: >>> On 26/07/2019 16:53, Severin Gehwolf wrote: > [...] > What exactly is being pushed > here? The following 4 patches: jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ hotspot: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/ langtools: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/langtools/webrev/ top: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/ Each of them has a reference to a plain patch file if you prefer to review that. Thanks, Severin >>> >>> Ok. HotSpot, JDK & top look fine, but there seem to be a lot of changes >>> in langtools. Are these original changes to this patch or are they >>> backports? Is there a reason langtools needs so much more work than the >>> others? >> The langtools Makefile changes appear to be larger because they required >> adding a load of definitions/macros that are already present in the >> Makefiles in the other trees (i.e. AWK, CAT etc, ZIP_UP_RESULTS, >> BUNDLE_UP_AND_EXIT etc). These changes look ok to me. > > Yes, exactly. The langools Makefile looks *very* different from > jdk/hotspot. In order to get some unified status of test results across > all three, these changes were needed. I've opted to make the langools > Makefile look more like the ones from jdk and hotspot. > > Old "make test" from top-level continues to work with these changes > (modulo -verbose:nopass=> summary change). > > Anyway, I had another look at this and made 8075546[1] another pre- > requisite which makes the langtools changes slightly smaller. Updated > webrevs set, thus, is: > > jdk: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ > hotspot: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/ > langtools: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/05/langtools/webrev/ > top: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/ > > Thanks, > Severin > > [1] https://bugs.openjdk.java.net/browse/JDK-8075546 > Right. That doesn't answer the question as to the origin of the changes. If I look at the langtools Makefile in OpenJDK 11, it doesn't have these changes. Should they not go there first if they are needed? Update releases are primarily for backports, so I'm dubious of anything that brings in a bunch of apparently new changes without making it clear why there are needed and why a backport is not appropriate. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew
Re: RFR(xxs): 8227170: (.hg)Ignore the JTwork and JTreport directories generated at the root of the repo
Thank you Erik. -Jaikiran On Monday, July 29, 2019, Erik Joelsson wrote: > This looks good to me. I can sponsor the change. > > /Erik > > On 2019-07-29 04:12, Jaikiran Pai wrote: > >> I got some more inputs from Stuart Marks on the linked JBS issue[1] and >> I've incorporated those in the latest updated webrev which is at [2]. >> >> I've tested this latest change locally on mercurial version 5.0.1 and it >> has worked as expected (now ignores JTreport and JTwork from the root as >> well as sub directories). Plus, with this change I haven't seen any >> files/directories that are now being unexpectedly not ignored. >> >> Anyone willing to review and sponsor this please? >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8227170 >> >> [2] http://cr.openjdk.java.net/~jpai/webrev/8227170/3/webrev/ >> >> -Jaikiran >> >> On 12/07/19 4:04 PM, Jaikiran Pai wrote: >> >>> Hello Dean, >>> >>> Thank you for testing this. I have now updated the webrev to use the >>> JTreport/* syntax and have also verified that it works for me too. It >>> correctly ignores both root level JTreport and JTwork directories and >>> any such sub-directories. I am on a macOS with: >>> >>> hg --version >>> Mercurial Distributed SCM (version 5.0.1) >>> (see https://mercurial-scm.org for more information) >>> >>> The updated webrev is at >>> http://cr.openjdk.java.net/~jpai/webrev/8227170/2/webrev/ >>> >>> -Jaikiran >>> >>> On 11/07/19 1:16 AM, dean.l...@oracle.com wrote: >>> The ** syntax isn't working for me in Mercurial 2.9, but the following: syntax: glob JTreport/* JTwork/* seems to work in both 2.9 and 4.6.1. This also seems to work: syntax: glob JTreport JTwork but it matches files and not just directories. dl On 7/10/19 4:48 AM, Jaikiran Pai wrote: > Ping. Anyone willing to review and sponsor this change? > > -Jaikiran > > On 03/07/19 5:43 PM, Jaikiran Pai wrote: > >> Hello, >> >> Can I please get a review and a sponsor for the patch for the >> enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8227170 >> ? >> >> The webrev containing the patch is here >> http://cr.openjdk.java.net/~jpai/webrev/8227170/00/webrev/ >> >> For some context about this change - there's been some discussion on >> this in the jdk-dev list here >> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003076.html >> . >> >> The patch in the webrev, does the following things: >> >> - In addition to ignoring the JTwork and JTreport sub-directories, >> this >> now also ignores these directories at the root of the repo. This patch >> uses "syntax: glob" to easily ignore such directories, instead of the >> (default) "regex" syntax. In the jdk-dev mailing list discussion, >> Gustavo suggested to continue using the regex syntax and listing the >> following in the .hgignore: >> >> .*JTreport/.* >> >> .*JTwork/.* >> >> But that would then end up ignoring directories of the form >> "foobarJTreport" and files under it like "foobarJTreport/blah.txt". I >> guess we can still stick with a regex syntax and come up with a regex >> which ignores these directories both at the root as well as >> sub-directories, maybe something like: >> >> (.*/JTreport/.*|^JTreport/.*) >> >> (.*/JTwork/.*|^JTwork/.*) >> >> but IMO, that appears a bit too complex when compared to the glob >> syntax >> that's used in the webrev. >> >> - The other change in this webrev is to ignore the >> src/utils/hsdis/build/ directory which gets generated when >> src/utils/hsdis is built. I included this in this patch based on >> Gustavo's suggestion in that linked thread. I verified that this is >> indeed the "build" location used by hsdis tool, by checking the >> src/utils/hsdis/Makefile as well src/utils/hsdis/README. >> >> Gustavo also had a suggestion that we ignore the "oprofile_data" >> directory/files. But I don't have knowledge of what those files are >> and >> didn't have a way to ascertain the right location/rule to add to the >> .hgignore. So I have not included that in the current version of this >> webrev. I'm however open to including this in the webrev if Gustavo >> and >> others feel that's OK/needed. >> >> -Jaikiran >> >> >>
Re: RFR(xxs): 8227170: (.hg)Ignore the JTwork and JTreport directories generated at the root of the repo
This looks good to me. I can sponsor the change. /Erik On 2019-07-29 04:12, Jaikiran Pai wrote: I got some more inputs from Stuart Marks on the linked JBS issue[1] and I've incorporated those in the latest updated webrev which is at [2]. I've tested this latest change locally on mercurial version 5.0.1 and it has worked as expected (now ignores JTreport and JTwork from the root as well as sub directories). Plus, with this change I haven't seen any files/directories that are now being unexpectedly not ignored. Anyone willing to review and sponsor this please? [1] https://bugs.openjdk.java.net/browse/JDK-8227170 [2] http://cr.openjdk.java.net/~jpai/webrev/8227170/3/webrev/ -Jaikiran On 12/07/19 4:04 PM, Jaikiran Pai wrote: Hello Dean, Thank you for testing this. I have now updated the webrev to use the JTreport/* syntax and have also verified that it works for me too. It correctly ignores both root level JTreport and JTwork directories and any such sub-directories. I am on a macOS with: hg --version Mercurial Distributed SCM (version 5.0.1) (see https://mercurial-scm.org for more information) The updated webrev is at http://cr.openjdk.java.net/~jpai/webrev/8227170/2/webrev/ -Jaikiran On 11/07/19 1:16 AM, dean.l...@oracle.com wrote: The ** syntax isn't working for me in Mercurial 2.9, but the following: syntax: glob JTreport/* JTwork/* seems to work in both 2.9 and 4.6.1. This also seems to work: syntax: glob JTreport JTwork but it matches files and not just directories. dl On 7/10/19 4:48 AM, Jaikiran Pai wrote: Ping. Anyone willing to review and sponsor this change? -Jaikiran On 03/07/19 5:43 PM, Jaikiran Pai wrote: Hello, Can I please get a review and a sponsor for the patch for the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8227170? The webrev containing the patch is here http://cr.openjdk.java.net/~jpai/webrev/8227170/00/webrev/ For some context about this change - there's been some discussion on this in the jdk-dev list here https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003076.html. The patch in the webrev, does the following things: - In addition to ignoring the JTwork and JTreport sub-directories, this now also ignores these directories at the root of the repo. This patch uses "syntax: glob" to easily ignore such directories, instead of the (default) "regex" syntax. In the jdk-dev mailing list discussion, Gustavo suggested to continue using the regex syntax and listing the following in the .hgignore: .*JTreport/.* .*JTwork/.* But that would then end up ignoring directories of the form "foobarJTreport" and files under it like "foobarJTreport/blah.txt". I guess we can still stick with a regex syntax and come up with a regex which ignores these directories both at the root as well as sub-directories, maybe something like: (.*/JTreport/.*|^JTreport/.*) (.*/JTwork/.*|^JTwork/.*) but IMO, that appears a bit too complex when compared to the glob syntax that's used in the webrev. - The other change in this webrev is to ignore the src/utils/hsdis/build/ directory which gets generated when src/utils/hsdis is built. I included this in this patch based on Gustavo's suggestion in that linked thread. I verified that this is indeed the "build" location used by hsdis tool, by checking the src/utils/hsdis/Makefile as well src/utils/hsdis/README. Gustavo also had a suggestion that we ignore the "oprofile_data" directory/files. But I don't have knowledge of what those files are and didn't have a way to ascertain the right location/rule to add to the .hgignore. So I have not included that in the current version of this webrev. I'm however open to including this in the webrev if Gustavo and others feel that's OK/needed. -Jaikiran
Re: RFR(xxs): 8227170: (.hg)Ignore the JTwork and JTreport directories generated at the root of the repo
I got some more inputs from Stuart Marks on the linked JBS issue[1] and I've incorporated those in the latest updated webrev which is at [2]. I've tested this latest change locally on mercurial version 5.0.1 and it has worked as expected (now ignores JTreport and JTwork from the root as well as sub directories). Plus, with this change I haven't seen any files/directories that are now being unexpectedly not ignored. Anyone willing to review and sponsor this please? [1] https://bugs.openjdk.java.net/browse/JDK-8227170 [2] http://cr.openjdk.java.net/~jpai/webrev/8227170/3/webrev/ -Jaikiran On 12/07/19 4:04 PM, Jaikiran Pai wrote: > Hello Dean, > > Thank you for testing this. I have now updated the webrev to use the > JTreport/* syntax and have also verified that it works for me too. It > correctly ignores both root level JTreport and JTwork directories and > any such sub-directories. I am on a macOS with: > > hg --version > Mercurial Distributed SCM (version 5.0.1) > (see https://mercurial-scm.org for more information) > > The updated webrev is at > http://cr.openjdk.java.net/~jpai/webrev/8227170/2/webrev/ > > -Jaikiran > > On 11/07/19 1:16 AM, dean.l...@oracle.com wrote: >> The ** syntax isn't working for me in Mercurial 2.9, but the following: >> >> syntax: glob >> JTreport/* >> JTwork/* >> >> seems to work in both 2.9 and 4.6.1. This also seems to work: >> >> syntax: glob >> JTreport >> JTwork >> >> but it matches files and not just directories. >> >> dl >> >> On 7/10/19 4:48 AM, Jaikiran Pai wrote: >>> Ping. Anyone willing to review and sponsor this change? >>> >>> -Jaikiran >>> >>> On 03/07/19 5:43 PM, Jaikiran Pai wrote: Hello, Can I please get a review and a sponsor for the patch for the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8227170? The webrev containing the patch is here http://cr.openjdk.java.net/~jpai/webrev/8227170/00/webrev/ For some context about this change - there's been some discussion on this in the jdk-dev list here https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003076.html. The patch in the webrev, does the following things: - In addition to ignoring the JTwork and JTreport sub-directories, this now also ignores these directories at the root of the repo. This patch uses "syntax: glob" to easily ignore such directories, instead of the (default) "regex" syntax. In the jdk-dev mailing list discussion, Gustavo suggested to continue using the regex syntax and listing the following in the .hgignore: .*JTreport/.* .*JTwork/.* But that would then end up ignoring directories of the form "foobarJTreport" and files under it like "foobarJTreport/blah.txt". I guess we can still stick with a regex syntax and come up with a regex which ignores these directories both at the root as well as sub-directories, maybe something like: (.*/JTreport/.*|^JTreport/.*) (.*/JTwork/.*|^JTwork/.*) but IMO, that appears a bit too complex when compared to the glob syntax that's used in the webrev. - The other change in this webrev is to ignore the src/utils/hsdis/build/ directory which gets generated when src/utils/hsdis is built. I included this in this patch based on Gustavo's suggestion in that linked thread. I verified that this is indeed the "build" location used by hsdis tool, by checking the src/utils/hsdis/Makefile as well src/utils/hsdis/README. Gustavo also had a suggestion that we ignore the "oprofile_data" directory/files. But I don't have knowledge of what those files are and didn't have a way to ascertain the right location/rule to add to the .hgignore. So I have not included that in the current version of this webrev. I'm however open to including this in the webrev if Gustavo and others feel that's OK/needed. -Jaikiran
Re: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u
On Mon, 2019-07-29 at 10:19 +0100, Andrew Dinn wrote: > On 26/07/2019 18:32, Andrew John Hughes wrote: > > On 26/07/2019 16:53, Severin Gehwolf wrote: [...] > > > > > > > What exactly is being pushed > > > > here? > > > > > > The following 4 patches: > > > > > > jdk: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ > > > hotspot: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/ > > > langtools: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/langtools/webrev/ > > > top: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/ > > > > > > Each of them has a reference to a plain patch file if you prefer to > > > review that. > > > > > > Thanks, > > > Severin > > > > > > > Ok. HotSpot, JDK & top look fine, but there seem to be a lot of changes > > in langtools. Are these original changes to this patch or are they > > backports? Is there a reason langtools needs so much more work than the > > others? > The langtools Makefile changes appear to be larger because they required > adding a load of definitions/macros that are already present in the > Makefiles in the other trees (i.e. AWK, CAT etc, ZIP_UP_RESULTS, > BUNDLE_UP_AND_EXIT etc). These changes look ok to me. Yes, exactly. The langools Makefile looks *very* different from jdk/hotspot. In order to get some unified status of test results across all three, these changes were needed. I've opted to make the langools Makefile look more like the ones from jdk and hotspot. Old "make test" from top-level continues to work with these changes (modulo -verbose:nopass=> summary change). Anyway, I had another look at this and made 8075546[1] another pre- requisite which makes the langtools changes slightly smaller. Updated webrevs set, thus, is: jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ hotspot: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/ langtools: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/05/langtools/webrev/ top: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/ Thanks, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8075546
Re: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u
On 26/07/2019 18:32, Andrew John Hughes wrote:
> On 26/07/2019 16:53, Severin Gehwolf wrote:
>> Hi Andrew,
>>
>> On Fri, 2019-07-26 at 14:46 +0100, Andrew John Hughes wrote:
>>> On 25/07/2019 16:02, Severin Gehwolf wrote:
>>>
>>> snip...
>>>
> Done now. I've added fix-request comments/labels to the above bugs and
> rebased on top of them. New jdk changeset:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/
>
> Test groups definition is the JDK 9 set plus :jdk_jdi test set (part of
> JDK-8198551 in later JDKs). This seems a reasonable test set. Modulo
> added intrinsics testing only relevant for 9+, see JDK-8132855 and JDK-
> 8132854.
>
> OK to push?
Any more thoughts?
Thanks,
Severin
>>>
>>> This webrev lists three different bug IDs.
>>
>> It beats me why webrev lists other bugs. The other two, 8075573 and
>> 8075544, were clean backports and were pushed after jdk8u-fix-yes got
>> added.
>>
>>> What exactly is being pushed
>>> here?
>>
>> The following 4 patches:
>>
>> jdk:
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/
>> hotspot:
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/
>> langtools:
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/langtools/webrev/
>> top:
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/
>>
>> Each of them has a reference to a plain patch file if you prefer to
>> review that.
>>
>> Thanks,
>> Severin
>>
>
> Ok. HotSpot, JDK & top look fine, but there seem to be a lot of changes
> in langtools. Are these original changes to this patch or are they
> backports? Is there a reason langtools needs so much more work than the
> others?
The langtools Makefile changes appear to be larger because they required
adding a load of definitions/macros that are already present in the
Makefiles in the other trees (i.e. AWK, CAT etc, ZIP_UP_RESULTS,
BUNDLE_UP_AND_EXIT etc). These changes look ok to me.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
