From jonathan.gibbons at oracle.com Wed May 4 01:28:29 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 03 May 2016 18:28:29 -0700 Subject: updating TestNG and JUnit for jtreg In-Reply-To: <57110BAC.7010909@oracle.com> References: <57110BAC.7010909@oracle.com> Message-ID: <5729503D.8080406@oracle.com> The recent updates to jdk9/dev will require the version of jtreg tagged as "jtreg4.2-b02". This has the same dependency requirements as the previous build, and all versions of jtreg4.1, meaning, if you could build it before, you should be able to build jtreg4.2-b02 the same way. Going forward, the next update to jtreg will require the following: * built with JDK 7 or later * TestNG 6.9.5 or later * JUnit 4.10 or later * JTHarness 4.6 or later These updates will enable a number of bug fixes and enhancements that have been blocked until now. Those folk that build jtreg may need to update their build scripts or build environment. Patches to make these changes are now in the jtreg repository. http://hg.openjdk.java.net/code-tools/jtreg -- Jon On 04/15/2016 08:41 AM, Jonathan Gibbons wrote: > This is a heads-up for those folk that build their own copy of jtreg, > especially folk outside Oracle. > > We are looking up update jtreg and the tests such that they will > require the following versions: > TestNG 6.9.5 > JUnit 4.10 > > This will allow tests to use newer API in TestNG, and will facilitate > improved support for JUnit tests, using TestNG mixed mode. > > --- > > Separately, we know that the external builds on cloudbees are broken, > and we are working to get that situation addressed. > > -- Jon From martinrb at google.com Wed May 4 20:49:38 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 4 May 2016 13:49:38 -0700 Subject: updating TestNG and JUnit for jtreg In-Reply-To: <5729503D.8080406@oracle.com> References: <57110BAC.7010909@oracle.com> <5729503D.8080406@oracle.com> Message-ID: Thanks! I was able to successfully build jtreg4.2-b02. One thing I keep stumbling over is the need to update BUILD_NUMBER in my scripts that build jtreg. The makefiles have BUILD_NUMBER = b00, but that has to be overridden at make time or the jtreg version check will fail later. It's a nice service to your users to update BUILD_NUMBER in the source code before creating the hg release tag (or abandon build numbers entirely). (OTOH, other openjdk builds have the same problem) On Tue, May 3, 2016 at 6:28 PM, Jonathan Gibbons wrote: > The recent updates to jdk9/dev will require the version of jtreg tagged as > "jtreg4.2-b02". > This has the same dependency requirements as the previous build, and all > versions of jtreg4.1, > meaning, if you could build it before, you should be able to build > jtreg4.2-b02 the same way. > > Going forward, the next update to jtreg will require the following: > * built with JDK 7 or later > * TestNG 6.9.5 or later > * JUnit 4.10 or later > * JTHarness 4.6 or later > > These updates will enable a number of bug fixes and enhancements that have > been blocked until now. > > Those folk that build jtreg may need to update their build scripts or build > environment. > > Patches to make these changes are now in the jtreg repository. > http://hg.openjdk.java.net/code-tools/jtreg > > -- Jon > > > > On 04/15/2016 08:41 AM, Jonathan Gibbons wrote: >> >> This is a heads-up for those folk that build their own copy of jtreg, >> especially folk outside Oracle. >> >> We are looking up update jtreg and the tests such that they will require >> the following versions: >> TestNG 6.9.5 >> JUnit 4.10 >> >> This will allow tests to use newer API in TestNG, and will facilitate >> improved support for JUnit tests, using TestNG mixed mode. >> >> --- >> >> Separately, we know that the external builds on cloudbees are broken, and >> we are working to get that situation addressed. >> >> -- Jon > > From jonathan.gibbons at oracle.com Wed May 4 21:16:20 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 04 May 2016 14:16:20 -0700 Subject: updating TestNG and JUnit for jtreg In-Reply-To: References: <57110BAC.7010909@oracle.com> <5729503D.8080406@oracle.com> Message-ID: <572A66A4.2030800@oracle.com> On 05/04/2016 01:49 PM, Martin Buchholz wrote: > Thanks! I was able to successfully build jtreg4.2-b02. > > One thing I keep stumbling over is the need to update BUILD_NUMBER in > my scripts that build jtreg. > The makefiles have BUILD_NUMBER = b00, but that has to be overridden > at make time or the jtreg version check will fail later. It's a nice > service to your users to update BUILD_NUMBER in the source code before > creating the hg release tag (or abandon build numbers entirely). > (OTOH, other openjdk builds have the same problem) Good suggestion to update the BUILD_NUMBER. For my part, it works to use b00 in my dev work, and that bypasses the version check, but I agree that is not desirable for general usage. The question is, when should the number be updated, and what should the build number show as, when building an otherwise untagged tip of the jtreg repo? For the cloudbees set up, I was suggesting to use a build number derived from the latest jtreg tag (for a tagged build) or b00 for a build of tip. I'm open to other general suggestions for good practice, here. -- Jon From martinrb at google.com Wed May 4 21:45:11 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 4 May 2016 14:45:11 -0700 Subject: updating TestNG and JUnit for jtreg In-Reply-To: <572A66A4.2030800@oracle.com> References: <57110BAC.7010909@oracle.com> <5729503D.8080406@oracle.com> <572A66A4.2030800@oracle.com> Message-ID: It's true that builds at random revisions are tricky. It probably doesn't matter that much when the build number is incremented. Either right after or right before a release works - I would do the latter. It should be very unusual for anyone other than jjg to use a non-tagged build. cloudbees tries to do "everything at tip" but unless there's energetic followup, that will result in a lot of brokenness. On Wed, May 4, 2016 at 2:16 PM, Jonathan Gibbons wrote: > > > On 05/04/2016 01:49 PM, Martin Buchholz wrote: >> >> Thanks! I was able to successfully build jtreg4.2-b02. >> >> One thing I keep stumbling over is the need to update BUILD_NUMBER in >> my scripts that build jtreg. >> The makefiles have BUILD_NUMBER = b00, but that has to be overridden >> at make time or the jtreg version check will fail later. It's a nice >> service to your users to update BUILD_NUMBER in the source code before >> creating the hg release tag (or abandon build numbers entirely). >> (OTOH, other openjdk builds have the same problem) > > > > Good suggestion to update the BUILD_NUMBER. > > For my part, it works to use b00 in my dev work, and that bypasses > the version check, but I agree that is not desirable for general usage. > > The question is, when should the number be updated, and what should > the build number show as, when building an otherwise untagged tip > of the jtreg repo? > > For the cloudbees set up, I was suggesting to use a build number > derived from the latest jtreg tag (for a tagged build) or b00 for a > build of tip. I'm open to other general suggestions for good > practice, here. > > -- Jon From jonathan.gibbons at oracle.com Wed May 4 21:51:02 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 04 May 2016 14:51:02 -0700 Subject: updating TestNG and JUnit for jtreg In-Reply-To: References: <57110BAC.7010909@oracle.com> <5729503D.8080406@oracle.com> <572A66A4.2030800@oracle.com> Message-ID: <572A6EC6.9080504@oracle.com> For a while, jigsaw/jake and jtreg were evolving fast enough that it didn't make sense to promote jtreg frequently, and it is still the case that we occasionally rely on using jtreg tip in conjunction with jigsaw/jake. And, internally, we do have CI systems building and using the upcoming new jtreg with a variety of jdki forests. Anyone using jdk9/dev forests, or any other jdk* forest should be OK to use the latest promotion of jtreg. -- Jon On 05/04/2016 02:45 PM, Martin Buchholz wrote: > It's true that builds at random revisions are tricky. It probably > doesn't matter that much when the build number is incremented. Either > right after or right before a release works - I would do the latter. > It should be very unusual for anyone other than jjg to use a > non-tagged build. cloudbees tries to do "everything at tip" but > unless there's energetic followup, that will result in a lot of > brokenness. > > On Wed, May 4, 2016 at 2:16 PM, Jonathan Gibbons > wrote: >> >> On 05/04/2016 01:49 PM, Martin Buchholz wrote: >>> Thanks! I was able to successfully build jtreg4.2-b02. >>> >>> One thing I keep stumbling over is the need to update BUILD_NUMBER in >>> my scripts that build jtreg. >>> The makefiles have BUILD_NUMBER = b00, but that has to be overridden >>> at make time or the jtreg version check will fail later. It's a nice >>> service to your users to update BUILD_NUMBER in the source code before >>> creating the hg release tag (or abandon build numbers entirely). >>> (OTOH, other openjdk builds have the same problem) >> >> >> Good suggestion to update the BUILD_NUMBER. >> >> For my part, it works to use b00 in my dev work, and that bypasses >> the version check, but I agree that is not desirable for general usage. >> >> The question is, when should the number be updated, and what should >> the build number show as, when building an otherwise untagged tip >> of the jtreg repo? >> >> For the cloudbees set up, I was suggesting to use a build number >> derived from the latest jtreg tag (for a tagged build) or b00 for a >> build of tip. I'm open to other general suggestions for good >> practice, here. >> >> -- Jon From weijun.wang at oracle.com Thu May 5 15:56:12 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 5 May 2016 23:56:12 +0800 Subject: Process output not in STDOUT Message-ID: <7A210FD7-80B4-411D-BF2B-221D9B2A518F@oracle.com> I launch a process inside a jtreg test: ProcessBuilder pb = new ProcessBuilder(cmd); Process p = pb.inheritIO().start(); I thought with inheritIO() the lines I System.out.println in the child process will appear in STDOUT of the jtr file. Instead, they appear in the log like this: Agent[0].stdout: PATH: /bin:/usr/bin How do I get them back into STDOUT? Thanks Max From jonathan.gibbons at oracle.com Thu May 5 17:21:15 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 05 May 2016 10:21:15 -0700 Subject: Process output not in STDOUT In-Reply-To: <7A210FD7-80B4-411D-BF2B-221D9B2A518F@oracle.com> References: <7A210FD7-80B4-411D-BF2B-221D9B2A518F@oracle.com> Message-ID: <572B810B.6060204@oracle.com> Max,, jtreg catches System.out and System.err, but not the low level OS stream stdout and sterr. -- Jon On 05/05/2016 08:56 AM, Wang Weijun wrote: > I launch a process inside a jtreg test: > > ProcessBuilder pb = new ProcessBuilder(cmd); > Process p = pb.inheritIO().start(); > > I thought with inheritIO() the lines I System.out.println in the child process will appear in STDOUT of the jtr file. Instead, they appear in the log like this: > > Agent[0].stdout: PATH: /bin:/usr/bin > > How do I get them back into STDOUT? > > Thanks > Max > From volker.simonis at gmail.com Thu May 12 15:10:48 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 12 May 2016 17:10:48 +0200 Subject: JTreg upwards compatibility? Message-ID: Hi, I wanted to ask if JTreg is supposed to be upwards compatible. I.e. should it be possible to run OpenJDK 7 and 8 regression tests with the newest JTreg version? If not, is there a source which describes the required JTreg version for successfully running the regression tests of the various OpenJDK releases? Which JTreg versions is Oracle using for running its OpenJDK 7 and 8 regression tests? Thank you and best regards, Volker From martinrb at google.com Thu May 12 15:30:52 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 12 May 2016 08:30:52 -0700 Subject: JTreg upwards compatibility? In-Reply-To: References: Message-ID: At Google, we try to run latest jtreg releases against jdk7 and jdk8. This is generally successful, but on each jtreg upgrade there's a handful of tests that start failing, mostly requiring an easy backport. Like most recently CustomizedLambdaFormTest On Thu, May 12, 2016 at 8:10 AM, Volker Simonis wrote: > Hi, > > I wanted to ask if JTreg is supposed to be upwards compatible. > > I.e. should it be possible to run OpenJDK 7 and 8 regression tests > with the newest JTreg version? > > If not, is there a source which describes the required JTreg version > for successfully running the regression tests of the various OpenJDK > releases? Which JTreg versions is Oracle using for running its OpenJDK > 7 and 8 regression tests? > > Thank you and best regards, > Volker From jonathan.gibbons at oracle.com Thu May 12 15:42:28 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 May 2016 08:42:28 -0700 Subject: JTreg upwards compatibility? In-Reply-To: References: Message-ID: <5734A464.3030106@oracle.com> On 05/12/2016 08:10 AM, Volker Simonis wrote: > Hi, > > I wanted to ask if JTreg is supposed to be upwards compatible. > > I.e. should it be possible to run OpenJDK 7 and 8 regression tests > with the newest JTreg version? > > If not, is there a source which describes the required JTreg version > for successfully running the regression tests of the various OpenJDK > releases? Which JTreg versions is Oracle using for running its OpenJDK > 7 and 8 regression tests? > > Thank you and best regards, > Volker Generally, the answer to your question is "yes". This is one of the reasons why we abandoned "samevm" mode a year or more ago, in favor of "agentvm" mode". The general policy statement is as follows: 1. jtreg can run tests all the way back to JDK 1.1 in othervm mode. (Although this is not routinely tested, these days.) 2. jtreg can run tests all the way back to JDK 5 in agentvm mode, although some tests use TestNG and JUnit, and the versions of these libraries recommended for use with JDK 9 tests require the use of JDK 7 or greater. However, I do not believe any of the standard JDK tests for OpenJDK 6 use TestNG or JUnit, so this should not be an issue. If it is, there are ways to override the versions of these libraries that are bundled with a jtreg build. There is a potential issue that can reasonably be addressed. If you run jtreg through the /test/Makefile mechanisms, the standard invocation is to use the same build/version of JDK to run jtreg as the one being tested. This was expedient at the time, although not the best practice. The current recommendation is to use a recent stable build of JDK to *run* jtreg, that is distinct from the version of JDK being tested. If you use /test/Makefile for JDK 6, this may require some changes to the makefiles. There is discussion about abandoning support for running tests on very old versions of JDK, such as for JDK 5 and earlier, and at the same time, raising the bar for the version used to *run* jtreg up to the latest supported version (currently JDK 8.) This would not affect the ability to be able to run tests in othervm mode or agentvm mode on all supported releases. One of the primary concerns is whether the latest supported version (i.e. JDK 8) can run on all the hardware/OS combinations used to test the oldest supported versions. However, this is becoming less of an issue these days, since JDK 8 does appear to be available on all relevant platforms. There is a general desire within the JDK team to use a single version of jtreg to run tests on all supported versions of JDK, and not to have to freeze or fork different versions of jtreg to run tests on different releases. -- Jon From volker.simonis at gmail.com Thu May 12 16:10:55 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 12 May 2016 18:10:55 +0200 Subject: JTreg upwards compatibility? In-Reply-To: <5734A464.3030106@oracle.com> References: <5734A464.3030106@oracle.com> Message-ID: Martin, Jonathan, thanks a lot for your answers! Regards, Volker On Thu, May 12, 2016 at 5:42 PM, Jonathan Gibbons wrote: > On 05/12/2016 08:10 AM, Volker Simonis wrote: >> >> Hi, >> >> I wanted to ask if JTreg is supposed to be upwards compatible. >> >> I.e. should it be possible to run OpenJDK 7 and 8 regression tests >> with the newest JTreg version? >> >> If not, is there a source which describes the required JTreg version >> for successfully running the regression tests of the various OpenJDK >> releases? Which JTreg versions is Oracle using for running its OpenJDK >> 7 and 8 regression tests? >> >> Thank you and best regards, >> Volker > > > Generally, the answer to your question is "yes". > > This is one of the reasons why we abandoned "samevm" mode > a year or more ago, in favor of "agentvm" mode". > > The general policy statement is as follows: > > 1. jtreg can run tests all the way back to JDK 1.1 in othervm mode. > (Although this is not routinely tested, these days.) > > 2. jtreg can run tests all the way back to JDK 5 in agentvm mode, > although some tests use TestNG and JUnit, and the versions > of these libraries recommended for use with JDK 9 tests require > the use of JDK 7 or greater. However, I do not believe any of > the standard JDK tests for OpenJDK 6 use TestNG or JUnit, so > this should not be an issue. If it is, there are ways to override > the versions of these libraries that are bundled with a jtreg build. > > There is a potential issue that can reasonably be addressed. If you > run jtreg through the /test/Makefile mechanisms, the standard > invocation is to use the same build/version of JDK to run jtreg as the > one being tested. This was expedient at the time, although not the > best practice. The current recommendation is to use a recent stable > build of JDK to *run* jtreg, that is distinct from the version of JDK > being tested. If you use /test/Makefile for JDK 6, this may > require some changes to the makefiles. > > There is discussion about abandoning support for running tests on very > old versions of JDK, such as for JDK 5 and earlier, and at the same time, > raising the bar for the version used to *run* jtreg up to the latest > supported version (currently JDK 8.) This would not affect the ability > to be able to run tests in othervm mode or agentvm mode on all > supported releases. One of the primary concerns is whether the latest > supported version (i.e. JDK 8) can run on all the hardware/OS > combinations used to test the oldest supported versions. However, > this is becoming less of an issue these days, since JDK 8 does appear > to be available on all relevant platforms. > > There is a general desire within the JDK team to use a single version of > jtreg to run tests on all supported versions of JDK, and not to have to > freeze > or fork different versions of jtreg to run tests on different releases. > > -- Jon > > > > From jonathan.gibbons at oracle.com Thu May 12 16:22:01 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 May 2016 09:22:01 -0700 Subject: JTreg upwards compatibility? In-Reply-To: References: Message-ID: <5734ADA9.1010908@oracle.com> martin, Can you elaborate a bit more on the issues you are seeing? Are they due to changes in jtreg itself, or for example, changes in the recommended libraries, like TestNG and JUnit? Can you point to JBS issues or changesets where tests have had to be updated? I did a quick search through Mercurial for jdk9/dev and jdk8u/jdk8u for changes to CustomizedLambdaFormTest, but didn't find anything obvious. -- Jon On 05/12/2016 08:30 AM, Martin Buchholz wrote: > At Google, we try to run latest jtreg releases against jdk7 and jdk8. > This is generally successful, but on each jtreg upgrade there's a > handful of tests that start failing, mostly requiring an easy > backport. Like most recently CustomizedLambdaFormTest > > On Thu, May 12, 2016 at 8:10 AM, Volker Simonis > wrote: >> Hi, >> >> I wanted to ask if JTreg is supposed to be upwards compatible. >> >> I.e. should it be possible to run OpenJDK 7 and 8 regression tests >> with the newest JTreg version? >> >> If not, is there a source which describes the required JTreg version >> for successfully running the regression tests of the various OpenJDK >> releases? Which JTreg versions is Oracle using for running its OpenJDK >> 7 and 8 regression tests? >> >> Thank you and best regards, >> Volker From martinrb at google.com Thu May 12 17:16:58 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 12 May 2016 10:16:58 -0700 Subject: JTreg upwards compatibility? In-Reply-To: <5734ADA9.1010908@oracle.com> References: <5734ADA9.1010908@oracle.com> Message-ID: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/041017.html We patched VarargsArrayTest and CustomizedLambdaFormTest On Thu, May 12, 2016 at 9:22 AM, Jonathan Gibbons wrote: > martin, > > Can you elaborate a bit more on the issues you are seeing? > Are they due to changes in jtreg itself, or for example, changes > in the recommended libraries, like TestNG and JUnit? > > Can you point to JBS issues or changesets where tests have > had to be updated? I did a quick search through Mercurial > for jdk9/dev and jdk8u/jdk8u for changes to > CustomizedLambdaFormTest, but didn't find anything obvious. From jonathan.gibbons at oracle.com Thu May 12 17:27:15 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 May 2016 10:27:15 -0700 Subject: JTreg upwards compatibility? In-Reply-To: References: <5734ADA9.1010908@oracle.com> Message-ID: <5734BCF3.1050101@oracle.com> Hi Martin, Yeah, mea culpa, that was an unintended side effect of a change to improve the reporting in .jtr files. The change was that previously, bootclasspath tests implied the use of the /othervm modifier. That was cleaned up/simplified as part of the work to document in the .jtr file which mode was being used and why. It's also a step in the direction of making the /othervm optional so that if you specify VM options, then jtreg will find and use a suitable VM (possibly creating it) instead of simply rejecting the test if it doesn't specify /othervm. -- Jon On 05/12/2016 10:16 AM, Martin Buchholz wrote: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/041017.html > We patched VarargsArrayTest and CustomizedLambdaFormTest > > On Thu, May 12, 2016 at 9:22 AM, Jonathan Gibbons > wrote: >> martin, >> >> Can you elaborate a bit more on the issues you are seeing? >> Are they due to changes in jtreg itself, or for example, changes >> in the recommended libraries, like TestNG and JUnit? >> >> Can you point to JBS issues or changesets where tests have >> had to be updated? I did a quick search through Mercurial >> for jdk9/dev and jdk8u/jdk8u for changes to >> CustomizedLambdaFormTest, but didn't find anything obvious. From martinrb at google.com Fri May 13 04:44:57 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 12 May 2016 21:44:57 -0700 Subject: JTreg upwards compatibility? In-Reply-To: <5734BCF3.1050101@oracle.com> References: <5734ADA9.1010908@oracle.com> <5734BCF3.1050101@oracle.com> Message-ID: On Thu, May 12, 2016 at 10:27 AM, Jonathan Gibbons wrote: > The change was that previously, bootclasspath tests implied the > use of the /othervm modifier. Relatedly ... the bootclasspath test feature seems to be undocumented. Should the tag spec be updated? From jonathan.gibbons at oracle.com Fri May 13 14:25:22 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 13 May 2016 07:25:22 -0700 Subject: JTreg upwards compatibility? In-Reply-To: References: <5734ADA9.1010908@oracle.com> <5734BCF3.1050101@oracle.com> Message-ID: <5735E3D2.2020608@oracle.com> On 05/12/2016 09:44 PM, Martin Buchholz wrote: > On Thu, May 12, 2016 at 10:27 AM, Jonathan Gibbons > wrote: >> The change was that previously, bootclasspath tests implied the >> use of the /othervm modifier. > Relatedly ... the bootclasspath test feature seems to be undocumented. > Should the tag spec be updated? Yes. I'll add it to the to-do list. -- Jon From martinrb at google.com Fri May 13 19:04:48 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 13 May 2016 12:04:48 -0700 Subject: jtreg 4.2-b02 -agentvm + jdk-9+118 = FAIL Message-ID: I tried updating jsr166 to jdk-9+118 today, but there's a snag - jtreg won't start. A simple repro is: jtreg -agentvm -testjdk:/home/martin/jdk/jdk-9-ea+118 . Agent[0].stdout: Bad value for -Xpatch, no module name specified Agent[0].stderr: Error: Could not create the Java Virtual Machine. Agent[0].stderr: Error: A fatal exception has occurred. Program will exit. It looks like jtreg is synthesizing an -Xpatch flag, but the syntax of that has changed. strace shows the flag "-Xpatch:/home/martin/jsr166/Xpatch/src/test/jtreg/JTwork/patches" Jonathan has been making -Xpatch related changes to jtreg in mercurial that may have already fixed it, but if so, making a 4.2-b03 release is urgent. It would be nice if there were one jtreg binary that could work with any jdk9 build, but that's understandably difficult. Of course, jsr166 wants to add its own -Xpatch flags; hopefully that will be able to peacefully coexist with whatever jtreg ends up doing. From Alan.Bateman at oracle.com Fri May 13 19:18:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 May 2016 20:18:17 +0100 Subject: jtreg 4.2-b02 -agentvm + jdk-9+118 = FAIL In-Reply-To: References: Message-ID: <57362879.8050602@oracle.com> On 13/05/2016 20:04, Martin Buchholz wrote: > I tried updating jsr166 to jdk-9+118 today, but there's a snag - jtreg > won't start. > A simple repro is: > > jtreg -agentvm -testjdk:/home/martin/jdk/jdk-9-ea+118 . > Agent[0].stdout: Bad value for -Xpatch, no module name specified > Agent[0].stderr: Error: Could not create the Java Virtual Machine. > Agent[0].stderr: Error: A fatal exception has occurred. Program will exit. > > It looks like jtreg is synthesizing an -Xpatch flag, but the syntax of > that has changed. > > strace shows the flag > "-Xpatch:/home/martin/jsr166/Xpatch/src/test/jtreg/JTwork/patches" > > Jonathan has been making -Xpatch related changes to jtreg in mercurial > that may have already fixed it, but if so, making a 4.2-b03 release is > urgent. It would be nice if there were one jtreg binary that could > work with any jdk9 build, but that's understandably difficult. > > Of course, jsr166 wants to add its own -Xpatch flags; hopefully that > will be able to peacefully coexist with whatever jtreg ends up doing. We transitioned to the new form of -Xpatch in jdk-9+118. jtreg 4.2 b02 can use the old or new form. It's configured via the useNewXpatch property in the test suite configuration. In jdk-9+118 then each test root had its TEST.ROOT changed to include useNewXpatch=true so that jtreg uses the new form of -Xpatch. For jtreg 4.2 b03 then Jon has removed support for the old form of -Xpatch. I don't think you need that just yet. So is this test suit a jsr166 test suite? If so then useNewXpatch=true or jtreg tip should be okay. I'll need to defer to Jon on peacefully co-existing as you are both patching java.base. You can only specify -Xpatch:java.base= only but the value can specify multiple locations. I suspect -othervm should be fine, -agentvm mode is where jtreg needs to inject. -Alan. From martinrb at google.com Fri May 13 19:29:16 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 13 May 2016 12:29:16 -0700 Subject: jtreg 4.2-b02 -agentvm + jdk-9+118 = FAIL In-Reply-To: <57362879.8050602@oracle.com> References: <57362879.8050602@oracle.com> Message-ID: On Fri, May 13, 2016 at 12:18 PM, Alan Bateman wrote: > On 13/05/2016 20:04, Martin Buchholz wrote: >> >> I tried updating jsr166 to jdk-9+118 today, but there's a snag - jtreg >> won't start. >> A simple repro is: >> >> jtreg -agentvm -testjdk:/home/martin/jdk/jdk-9-ea+118 . >> Agent[0].stdout: Bad value for -Xpatch, no module name specified >> Agent[0].stderr: Error: Could not create the Java Virtual Machine. >> Agent[0].stderr: Error: A fatal exception has occurred. Program will exit. >> >> It looks like jtreg is synthesizing an -Xpatch flag, but the syntax of >> that has changed. >> >> strace shows the flag >> "-Xpatch:/home/martin/jsr166/Xpatch/src/test/jtreg/JTwork/patches" >> >> Jonathan has been making -Xpatch related changes to jtreg in mercurial >> that may have already fixed it, but if so, making a 4.2-b03 release is >> urgent. It would be nice if there were one jtreg binary that could >> work with any jdk9 build, but that's understandably difficult. >> >> Of course, jsr166 wants to add its own -Xpatch flags; hopefully that >> will be able to peacefully coexist with whatever jtreg ends up doing. > > We transitioned to the new form of -Xpatch in jdk-9+118. > > jtreg 4.2 b02 can use the old or new form. It's configured via the > useNewXpatch property in the test suite configuration. In jdk-9+118 then > each test root had its TEST.ROOT changed to include useNewXpatch=true so > that jtreg uses the new form of -Xpatch. Thanks! That explains why I can still run jtreg -agentvm on openjdk itself. (But useNewXpatch feels wrong because it's not a property of the test suite itself, but of the testjdk ...) > For jtreg 4.2 b03 then Jon has removed support for the old form of -Xpatch. > I don't think you need that just yet. I'll probably wait for 4.2-b03. From Alan.Bateman at oracle.com Fri May 13 19:38:05 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 May 2016 20:38:05 +0100 Subject: jtreg 4.2-b02 -agentvm + jdk-9+118 = FAIL In-Reply-To: References: <57362879.8050602@oracle.com> Message-ID: <57362D1D.2010001@oracle.com> On 13/05/2016 20:29, Martin Buchholz wrote: > : > Thanks! That explains why I can still run jtreg -agentvm on openjdk itself. > (But useNewXpatch feels wrong because it's not a property of the test > suite itself, but of the testjdk ...) > I agree but it was just for transition purposes to keep existing jtreg usages working. It's removed from jtreg tip and we'll drop it from TEST.ROOT once there is an overall upgrade to jtreg 4.2 b03. -Alan From martinrb at google.com Tue May 17 06:28:33 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 16 May 2016 23:28:33 -0700 Subject: jtreg hangs when secondary thread throws Message-ID: Here's a minimal test with a throwing non-main thread: /* @test */ public class YY { public static void main(String[] args) throws Exception { Thread t = new Thread(() -> { throw new Error(); }, "justDie"); t.start(); t.join(); } } If I run this with jtreg 4.2-b02 + jdk9+118, I get a mysterious timeout. Checking the stacks during the hang, I see no trace of YY.main (it was interrupted early), but I do see: "justDie" #14 prio=5 os_prio=0 tid=0x00007fb7b0001800 nid=0x230b in Object.wait() [0x00007fb7f1d9f000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(java.base at 9-ea/Native Method) - waiting on <0x00000006d5613070> (a java.lang.Thread) at java.lang.Thread.join(java.base at 9-ea/Thread.java:1321) - waiting to re-lock in wait() <0x00000006d5613070> (a java.lang.Thread) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMThreadGroup.cleanup(MainActionHelper.java:306) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMThreadGroup.uncaughtException(MainActionHelper.java:273) - locked <0x00000006d5626308> (a com.sun.javatest.regtest.agent.MainActionHelper$SameVMThreadGroup) at java.lang.Thread.dispatchUncaughtException(java.base at 9-ea/Thread.java:2016) so something's gone wrong with the uncaught exception handling. From david.holmes at oracle.com Tue May 17 06:52:12 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 May 2016 16:52:12 +1000 Subject: jtreg hangs when secondary thread throws In-Reply-To: References: Message-ID: On 17/05/2016 4:28 PM, Martin Buchholz wrote: > Here's a minimal test with a throwing non-main thread: > > /* @test */ > public class YY { > public static void main(String[] args) throws Exception { > Thread t = new Thread(() -> { throw new Error(); }, "justDie"); > t.start(); > t.join(); > } > } > > If I run this with jtreg 4.2-b02 + jdk9+118, I get a mysterious timeout. > > Checking the stacks during the hang, I see no trace of YY.main (it was > interrupted early), but I do see: > > "justDie" #14 prio=5 os_prio=0 tid=0x00007fb7b0001800 nid=0x230b in > Object.wait() [0x00007fb7f1d9f000] > java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(java.base at 9-ea/Native Method) > - waiting on <0x00000006d5613070> (a java.lang.Thread) > at java.lang.Thread.join(java.base at 9-ea/Thread.java:1321) It would be interesting to know what thread it is trying to join(). David ----- > - waiting to re-lock in wait() <0x00000006d5613070> (a java.lang.Thread) > at com.sun.javatest.regtest.agent.MainActionHelper$SameVMThreadGroup.cleanup(MainActionHelper.java:306) > at com.sun.javatest.regtest.agent.MainActionHelper$SameVMThreadGroup.uncaughtException(MainActionHelper.java:273) > - locked <0x00000006d5626308> (a > com.sun.javatest.regtest.agent.MainActionHelper$SameVMThreadGroup) > at java.lang.Thread.dispatchUncaughtException(java.base at 9-ea/Thread.java:2016) > > so something's gone wrong with the uncaught exception handling. > From martinrb at google.com Wed May 18 15:30:09 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 18 May 2016 08:30:09 -0700 Subject: jtreg hangs when secondary thread throws In-Reply-To: References: Message-ID: I turned this into a proper bug https://bugs.openjdk.java.net/browse/CODETOOLS-7901682