From christoph.langer at sap.com Wed Mar 6 14:59:57 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 6 Mar 2019 14:59:57 +0000 Subject: RFR: CODETOOLS-7902417: jtreg build with build-all.sh should work on cygwin Message-ID: Hi, I tried to build jtreg with the cool script ?build-all.sh? today. It?s great because it resolves and builds all dependencies. ?? However, I used Cygwin on my windows box and had to figure out that it would not work out of the box there, as claimed on http://openjdk.java.net/jtreg/build.html I made a few modifications, mainly to the script. I also had to change a make file where I had to generate options for a jar call into a command file because it was too much for the command line. Please review my changes and if you like it, please sponsor it ?? Webrev: http://cr.openjdk.java.net/~clanger/webrevs/CODETOOLS-7902417.0/ Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902417 I, however, just built with Cygwin. Someone needs to check that I didn?t break things for Unix/Linux/Mac? Thanks and best regards Christoph From christoph.langer at sap.com Wed Mar 6 15:47:21 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 6 Mar 2019 15:47:21 +0000 Subject: RFR: CODETOOLS-7902418: jtreg fails to guarantee a cleaned scratch directory sometimes on windows and CODETOOLS-7901369: jtreg should be able to clean up read-only files under result dir Message-ID: Hi, here?s the fix that I actually wanted to build/test when I saw the Cygwin issue? In our CI test infrastructure, we use jtreg in agentvm mode to run tests in parallel. On Windows we regularly see an issue that bubbles up because the 2 tests: jdk/modules/scenarios/automaticmodules/RunWithAutomaticModules.java jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java are run one after another in the same agent vm, hence in the same scratch directory. The issue boils down to the Windows DeleteFileW API which is used under the covers of java.io.File::delete. It does not always guarantee an instantaneous deletion of a file. When there are handles open to a file, it'll set a delete on close flag and defer deletion to a point when the last open handle is closed. The problematic behavior in the tests is that the first test (RunWithAutomaticModules.java) would create a jar file to be used on the module path. Due to some compilation operation, I think the process keeps the handle to the jar file open. When the next test (OverlappingPackagesTest.java) is run (in the same VM that still holds the open file handle), jtreg empties the scratch directory and thinks it is successful. But then the test stumbles over the zombie file which is still there and cannot be accessed. Jtreg can be improved to check if a file was really deleted after the call to File::delete. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/CODETOOLS-7902418.0/ Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902418 I verified that this will fix the issue that we observe. I?d think that the performance overhead for an additional call to File::exists is neglectable. This would also resolve this bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901369 which is possible now as https://bugs.openjdk.java.net/browse/CODETOOLS-7901611 has been resolved, updating the jtreg baseline to JDK 1.7. If you like the fix, I would also need a sponsor ?? Thanks & Best regards Christoph From jonathan.gibbons at oracle.com Wed Mar 6 16:11:49 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 6 Mar 2019 08:11:49 -0800 Subject: RFR: CODETOOLS-7902418: jtreg fails to guarantee a cleaned scratch directory sometimes on windows and CODETOOLS-7901369: jtreg should be able to clean up read-only files under result dir In-Reply-To: References: Message-ID: <451792b7-09f0-2e49-9c29-725f906fd468@oracle.com> Christoph, Thanks for looking at this. It looks ok, but I'll take a more detailed look later today, and will sponsor the change unless there is reason to get back to you. -- Jon On 3/6/19 7:47 AM, Langer, Christoph wrote: > Hi, > > here?s the fix that I actually wanted to build/test when I saw the Cygwin issue? > > In our CI test infrastructure, we use jtreg in agentvm mode to run tests in parallel. On Windows we regularly see an issue that bubbles up because the 2 tests: > jdk/modules/scenarios/automaticmodules/RunWithAutomaticModules.java > jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java > are run one after another in the same agent vm, hence in the same scratch directory. > > The issue boils down to the Windows DeleteFileW API which is used under the covers of java.io.File::delete. It does not always guarantee an instantaneous deletion of a file. When there are handles open to a file, it'll set a delete on close flag and defer deletion to a point when the last open handle is closed. > > The problematic behavior in the tests is that the first test (RunWithAutomaticModules.java) would create a jar file to be used on the module path. Due to some compilation operation, I think the process keeps the handle to the jar file open. When the next test (OverlappingPackagesTest.java) is run (in the same VM that still holds the open file handle), jtreg empties the scratch directory and thinks it is successful. But then the test stumbles over the zombie file which is still there and cannot be accessed. > > Jtreg can be improved to check if a file was really deleted after the call to File::delete. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/CODETOOLS-7902418.0/ > Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902418 > > I verified that this will fix the issue that we observe. I?d think that the performance overhead for an additional call to File::exists is neglectable. > > This would also resolve this bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901369 which is possible now as https://bugs.openjdk.java.net/browse/CODETOOLS-7901611 has been resolved, updating the jtreg baseline to JDK 1.7. > > If you like the fix, I would also need a sponsor ?? > > Thanks & Best regards > Christoph > From jonathan.gibbons at oracle.com Wed Mar 6 16:16:52 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 6 Mar 2019 08:16:52 -0800 Subject: RFR: CODETOOLS-7902417: jtreg build with build-all.sh should work on cygwin In-Reply-To: References: Message-ID: <7c6af7fe-34ed-6706-736b-dd023546e2b4@oracle.com> Christoph, I'll take a look at this today; I can check Linux/Mac, and sponsor it if all seems OK. At some point, someone is going to want support for WSL (Windows Subsystem for Linux) as well, but I realize that is only for Windows 10. -- Jon On 3/6/19 6:59 AM, Langer, Christoph wrote: > Hi, > > I tried to build jtreg with the cool script ?build-all.sh? today. It?s great because it resolves and builds all dependencies. ?? > > However, I used Cygwin on my windows box and had to figure out that it would not work out of the box there, as claimed on http://openjdk.java.net/jtreg/build.html > > I made a few modifications, mainly to the script. I also had to change a make file where I had to generate options for a jar call into a command file because it was too much for the command line. > > Please review my changes and if you like it, please sponsor it ?? > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/CODETOOLS-7902417.0/ > Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902417 > > I, however, just built with Cygwin. Someone needs to check that I didn?t break things for Unix/Linux/Mac? > > Thanks and best regards > Christoph > From christoph.langer at sap.com Thu Mar 7 15:38:04 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 7 Mar 2019 15:38:04 +0000 Subject: RFR: CODETOOLS-7902418: jtreg fails to guarantee a cleaned scratch directory sometimes on windows and CODETOOLS-7901369: jtreg should be able to clean up read-only files under result dir In-Reply-To: <451792b7-09f0-2e49-9c29-725f906fd468@oracle.com> References: <451792b7-09f0-2e49-9c29-725f906fd468@oracle.com> Message-ID: Thanks, Jon. Looking forward to test the final fix in our CI. > -----Original Message----- > From: Jonathan Gibbons > Sent: Mittwoch, 6. M?rz 2019 17:12 > To: Langer, Christoph ; code-tools- > dev at openjdk.java.net > Cc: Zeller, Arno > Subject: Re: RFR: CODETOOLS-7902418: jtreg fails to guarantee a cleaned > scratch directory sometimes on windows and CODETOOLS-7901369: jtreg > should be able to clean up read-only files under result dir > > Christoph, > > Thanks for looking at this. It looks ok, but I'll take a more detailed > look later today, and will sponsor the change unless there is reason to > get back to you. > > -- Jon > > On 3/6/19 7:47 AM, Langer, Christoph wrote: > > Hi, > > > > here?s the fix that I actually wanted to build/test when I saw the Cygwin > issue? > > > > In our CI test infrastructure, we use jtreg in agentvm mode to run tests in > parallel. On Windows we regularly see an issue that bubbles up because the > 2 tests: > > > jdk/modules/scenarios/automaticmodules/RunWithAutomaticModules.java > > > jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java > > are run one after another in the same agent vm, hence in the same scratch > directory. > > > > The issue boils down to the Windows DeleteFileW API which is used under > the covers of java.io.File::delete. It does not always guarantee an > instantaneous deletion of a file. When there are handles open to a file, it'll > set a delete on close flag and defer deletion to a point when the last open > handle is closed. > > > > The problematic behavior in the tests is that the first test > (RunWithAutomaticModules.java) would create a jar file to be used on the > module path. Due to some compilation operation, I think the process keeps > the handle to the jar file open. When the next test > (OverlappingPackagesTest.java) is run (in the same VM that still holds the > open file handle), jtreg empties the scratch directory and thinks it is > successful. But then the test stumbles over the zombie file which is still there > and cannot be accessed. > > > > Jtreg can be improved to check if a file was really deleted after the call to > File::delete. > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/CODETOOLS- > 7902418.0/ > > Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902418 > > > > I verified that this will fix the issue that we observe. I?d think that the > performance overhead for an additional call to File::exists is neglectable. > > > > This would also resolve this bug: > https://bugs.openjdk.java.net/browse/CODETOOLS-7901369 which is > possible now as https://bugs.openjdk.java.net/browse/CODETOOLS- > 7901611 has been resolved, updating the jtreg baseline to JDK 1.7. > > > > If you like the fix, I would also need a sponsor ?? > > > > Thanks & Best regards > > Christoph > > From jonathan.gibbons at oracle.com Thu Mar 7 19:31:36 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 7 Mar 2019 11:31:36 -0800 Subject: RFR: CODETOOLS-7902417: jtreg build with build-all.sh should work on cygwin In-Reply-To: <7c6af7fe-34ed-6706-736b-dd023546e2b4@oracle.com> References: <7c6af7fe-34ed-6706-736b-dd023546e2b4@oracle.com> Message-ID: <4720f66b-a73b-7e58-b762-bb4bcb7d47c7@oracle.com> Christoph, I have pushed this change, with one minor alteration ... in the edit for Rules.gmk, I changed the name of the temporary file to follow the convention used for naming of similar file manifest.txt found nearby. -- Jon On 03/06/2019 08:16 AM, Jonathan Gibbons wrote: > Christoph, > > I'll take a look at this today; I can check Linux/Mac, and sponsor it > if all seems OK. > > At some point, someone is going to want support for WSL (Windows > Subsystem for Linux) as well, but I realize that is only for Windows 10. > > -- Jon > > On 3/6/19 6:59 AM, Langer, Christoph wrote: >> Hi, >> >> I tried to build jtreg with the cool script ?build-all.sh? today. >> It?s great because it resolves and builds all dependencies. ?? >> >> However, I used Cygwin on my windows box and had to figure out that >> it would not work out of the box there, as claimed on >> http://openjdk.java.net/jtreg/build.html >> >> I made a few modifications, mainly to the script. I also had to >> change a make file where I had to generate options for a jar call >> into a command file because it was too much for the command line. >> >> Please review my changes and if you like it, please sponsor it ?? >> >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/CODETOOLS-7902417.0/ >> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902417 >> >> I, however, just built with Cygwin. Someone needs to check that I >> didn?t break things for Unix/Linux/Mac? >> >> Thanks and best regards >> Christoph >> From jonathan.gibbons at oracle.com Thu Mar 7 19:32:12 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 7 Mar 2019 11:32:12 -0800 Subject: RFR: CODETOOLS-7902418: jtreg fails to guarantee a cleaned scratch directory sometimes on windows and CODETOOLS-7901369: jtreg should be able to clean up read-only files under result dir In-Reply-To: References: <451792b7-09f0-2e49-9c29-725f906fd468@oracle.com> Message-ID: Pushed. -- Jon On 03/07/2019 07:38 AM, Langer, Christoph wrote: > Thanks, Jon. > > Looking forward to test the final fix in our CI. > >> -----Original Message----- >> From: Jonathan Gibbons >> Sent: Mittwoch, 6. M?rz 2019 17:12 >> To: Langer, Christoph ; code-tools- >> dev at openjdk.java.net >> Cc: Zeller, Arno >> Subject: Re: RFR: CODETOOLS-7902418: jtreg fails to guarantee a cleaned >> scratch directory sometimes on windows and CODETOOLS-7901369: jtreg >> should be able to clean up read-only files under result dir >> >> Christoph, >> >> Thanks for looking at this. It looks ok, but I'll take a more detailed >> look later today, and will sponsor the change unless there is reason to >> get back to you. >> >> -- Jon >> >> On 3/6/19 7:47 AM, Langer, Christoph wrote: >>> Hi, >>> >>> here?s the fix that I actually wanted to build/test when I saw the Cygwin >> issue? >>> In our CI test infrastructure, we use jtreg in agentvm mode to run tests in >> parallel. On Windows we regularly see an issue that bubbles up because the >> 2 tests: >> jdk/modules/scenarios/automaticmodules/RunWithAutomaticModules.java >> jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java >>> are run one after another in the same agent vm, hence in the same scratch >> directory. >>> The issue boils down to the Windows DeleteFileW API which is used under >> the covers of java.io.File::delete. It does not always guarantee an >> instantaneous deletion of a file. When there are handles open to a file, it'll >> set a delete on close flag and defer deletion to a point when the last open >> handle is closed. >>> The problematic behavior in the tests is that the first test >> (RunWithAutomaticModules.java) would create a jar file to be used on the >> module path. Due to some compilation operation, I think the process keeps >> the handle to the jar file open. When the next test >> (OverlappingPackagesTest.java) is run (in the same VM that still holds the >> open file handle), jtreg empties the scratch directory and thinks it is >> successful. But then the test stumbles over the zombie file which is still there >> and cannot be accessed. >>> Jtreg can be improved to check if a file was really deleted after the call to >> File::delete. >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/CODETOOLS- >> 7902418.0/ >>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902418 >>> >>> I verified that this will fix the issue that we observe. I?d think that the >> performance overhead for an additional call to File::exists is neglectable. >>> This would also resolve this bug: >> https://bugs.openjdk.java.net/browse/CODETOOLS-7901369 which is >> possible now as https://bugs.openjdk.java.net/browse/CODETOOLS- >> 7901611 has been resolved, updating the jtreg baseline to JDK 1.7. >>> If you like the fix, I would also need a sponsor ?? >>> >>> Thanks & Best regards >>> Christoph >>> From jonathan.gibbons at oracle.com Fri Mar 8 21:06:38 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 8 Mar 2019 13:06:38 -0800 Subject: Result: New Code Tools Committer: Eric Caspole In-Reply-To: References: <12b8a62e-a4df-98ec-f208-7daad4242ab6@oracle.com> Message-ID: Voting for Eric Caspole [1] is now closed. Yes: 2 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Jonathan Gibbons [1] https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-February/000503.html On 02/20/2019 12:58 PM, Jonathan Gibbons wrote: > (Resend, with correct subject line) > > I hereby nominate Eric Caspole to Code Tools Committer. > > Eric is the primary maintainer of the benchmarks in the Code Tools > jmh-jdk-microbenchmarks repo. He is also a JDK Committer. > > Votes are due by 1pm Pacific, March 6, 2019. > > Only current Code Tools Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From jonathan.gibbons at oracle.com Fri Mar 8 21:09:14 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 8 Mar 2019 13:09:14 -0800 Subject: Result: New Code Tools Committer: Victor Rudometov In-Reply-To: <99782188-0d2a-fad6-dcf6-5e507c6a8d96@oracle.com> References: <99782188-0d2a-fad6-dcf6-5e507c6a8d96@oracle.com> Message-ID: <801d59e5-af2e-0054-6fd9-d69872fd0c45@oracle.com> |Voting for Victor Rudometov [1] is now closed. Yes: 4 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Jonathan Gibbons [1] https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-February/000504.html| On 02/20/2019 02:19 PM, Jonathan Gibbons wrote: > > I hereby nominate Victor Rudometov to Code Tools Committer. > > Victor has contributed a number of changesets to the Code Tools > "sigtest" repo, and is looking to do more. > > http://hg.openjdk.java.net/code-tools/sigtest > > Votes are due by 2:30 PM, Pacific, March 6, 2019. > > Only current Code Tools Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From andrewluotechnologies at outlook.com Tue Mar 19 05:06:25 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Tue, 19 Mar 2019 05:06:25 +0000 Subject: RFR: CODETOOLS-7902417: jtreg build with build-all.sh should work on cygwin In-Reply-To: <4720f66b-a73b-7e58-b762-bb4bcb7d47c7@oracle.com> References: <7c6af7fe-34ed-6706-736b-dd023546e2b4@oracle.com> <4720f66b-a73b-7e58-b762-bb4bcb7d47c7@oracle.com> Message-ID: I'm a little bit late to this but actually WSL is already working I believe; building using build-all.sh worked out of the box the first time I tried with WSL (several months ago). Thanks, -Andrew -----Original Message----- From: code-tools-dev On Behalf Of Jonathan Gibbons Sent: Thursday, March 7, 2019 11:32 AM To: Langer, Christoph ; code-tools-dev at openjdk.java.net Subject: Re: RFR: CODETOOLS-7902417: jtreg build with build-all.sh should work on cygwin Christoph, I have pushed this change, with one minor alteration ... in the edit for Rules.gmk, I changed the name of the temporary file to follow the convention used for naming of similar file manifest.txt found nearby. -- Jon On 03/06/2019 08:16 AM, Jonathan Gibbons wrote: > Christoph, > > I'll take a look at this today; I can check Linux/Mac, and sponsor it > if all seems OK. > > At some point, someone is going to want support for WSL (Windows > Subsystem for Linux) as well, but I realize that is only for Windows 10. > > -- Jon > > On 3/6/19 6:59 AM, Langer, Christoph wrote: >> Hi, >> >> I tried to build jtreg with the cool script ?build-all.sh? today. >> It?s great because it resolves and builds all dependencies. ?? >> >> However, I used Cygwin on my windows box and had to figure out that >> it would not work out of the box there, as claimed on >> http://openjdk.java.net/jtreg/build.html >> >> I made a few modifications, mainly to the script. I also had to >> change a make file where I had to generate options for a jar call >> into a command file because it was too much for the command line. >> >> Please review my changes and if you like it, please sponsor it ?? >> >> Webrev: >> http://cr.openjdk.java.net/~clanger/webrevs/CODETOOLS-7902417.0/ >> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902417 >> >> I, however, just built with Cygwin. Someone needs to check that I >> didn?t break things for Unix/Linux/Mac? >> >> Thanks and best regards >> Christoph >> From gnu.andrew at redhat.com Fri Mar 22 00:59:18 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 22 Mar 2019 00:59:18 +0000 Subject: [RFR] 7902421: jcheck fails with mercurial 4.8 Message-ID: <9d5abe47-5408-6ebe-8e97-765396889adc@redhat.com> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902421 Webrev: https://cr.openjdk.java.net/~andrew/codetools/7902421/webrev.01/ Mercurial pull requests started failing after upgrading to 4.8.1: File "/home/andrew/projects/openjdk/jcheck/jcheck.py", line 745, in hook ch.check(repo.changelog.node(rev)) File "/home/andrew/projects/openjdk/jcheck/jcheck.py", line 688, in check ctx = context.changectx(self.repo, node) This seems to be because context.changectx now takes an additional argument: ArgSpec(args=['self', 'repo', 'rev', 'node'], varargs=None, keywords=None, defaults=None) so I made changes to pass through the rev argument. This fixes the problem and I can pull in changes again. I couldn't see any clear mention in the Mercurial code of why this rev argument is now required or any explanation of the change on their website. Not being overly familiar with either the Mercurial or jcheck code, this may be the wrong approach, but it seems to be working so far for me. -- 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