From jonathan.gibbons at oracle.com Fri Nov 1 08:30:31 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 01 Nov 2013 08:30:31 -0700 Subject: building jtreg, and running tests In-Reply-To: References: <5271B563.7010301@oracle.com> <5272BD38.6090409@orange.fr> <527314A7.3040500@oracle.com> Message-ID: <5273C917.1040400@oracle.com> On 10/31/2013 08:16 PM, Mike Duigou wrote: > > On Oct 31 2013, at 19:40 , Jonathan Gibbons > > wrote: >> >> Earlier today, I pushed fixes that should allow /cygdrive paths to be >> used when building jtreg. >> http://hg.openjdk.java.net/code-tools/jtreg/rev/8f44b4e1f37b >> and tolerate the use of /cygdrive in JT_HOME >> http://hg.openjdk.java.net/code-tools/jtreg/rev/caf396306070 >> >> Your example has opened up another case that would be good to >> address, command line args to jtreg. For those folk that invoke >> jtreg through the standard script, we could reasonably translate >> /cygdrive/X into X: for all drive letters. > > I believe we will have to move towards this. Look for this later today. I ran out of time and energy yesterday, but I know the edits to I want to make. > >> Those folk that invoke jtreg.jar file directly will need to do the >> translation themselves. > > I agree. The java -jar command should only be seeing native paths. > >> Some folk may use jtreg by means of the various test targets in the >> various Makefiles. I don't know what the conventions are for >> accepting /cygdrive paths in the makefiles, or whether the mixed >> format is expected/required. Maybe someone more familiar with using >> those makefiles on Windows with Cygwin can comment. > > I have been working on the test/Makefiles and have been thinking where > to properly make the split between native paths and cygwin paths. > Currently it's done all in the makefile but perhaps in the jtreg > script wrapper might be a better place (or more convenient) since it > is going to get invoked anyway and will always be invoked from within > a posix-like environment like either cygwin or mingw. This would also > eliminate the need to have platform specific code in the test > makefiles which would be nice. I was using the old JDK makefiles as a guideline/reference, where the methodology within the makefiles was to use mixed paths (drive letters plus "/"). There are comments from Kelly within the makefiles as to the rationale. It would be interesting to talk to the current build team about the methodology within the new build, and to follow their lead within the test makefiles. > > Another option I have considered: Windows command scripts to replace > or supplement the jtreg and jtdiff scripts that would be fully windows > native. I'd like to consider eliminating the duplicate bin directories > and going with a single bin directory like Ant does. I'm not sure what you mean here. By "fully windows native" do you mean a .BAT file? How does that go along with the use of a single bin directory? FWIW, I'd support going with a single bin directory; the duplicate directoris are a historical anachronism; the only reason I've held off is to avoid breaking infrastructure which assumes the existence of the extra path level. Maybe if enough systems use test/Makefile, we can paper over the transition in test/Makefile. -- Jon > > Mike > > >> >> For another day: >> >> What about MSYS/MinGW? >> If you want your head to explode, try reading >> http://www.mingw.org/wiki/Posix_path_conversion >> >> -- Jon >> >> >> On 10/31/2013 01:27 PM, Francis ANDRE wrote: >>> Hi Jon >>> >>> I run all the jdk8 test on WXP/Cygwin with your latest version of >>> jtreg and found this problem: >>> >>> $ >>> JT_JAVA=/cygdrive/Z/JDK/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image >>> Z:/JDK/jt >>> reg/build/images/jtreg/win32/bin/jtreg -J-Xmx512m >>> -vmoption:-Xmx768m -a -ignore:quiet -v:fail,e >>> rror,nopass >>> -r:Z:/JDK/jdk8/LANGTO~1/build/WINDOW~1/test/LANGTO~1/jtreg/JTreport >>> -w:Z:/JDK/jdk8/LANGTO~1/build/WINDOW~1/test/LANGTO~1/jtreg/JTwork >>> -jdk:/cygdrive/Z/JDK/j >>> dk8/build/windows-x86-normal-server-release/images/j2sdk-image >>> -agentvm -concurrency:2 >>> . || ( status=$?; if [ $status -ge 3 ]; then exit >>> $status ; fi ; echo $status > Z:/ >>> JDK/jdk8/LANGTO~1/build/WINDOW~1/test/LANGTO~1/jtreg/status.txt ) >>> Error: JDK not found: >>> \cygdrive\Z\JDK\jdk8\build\windows-x86-normal-server-release\images\j2sdk-imag >>> e >>> >>> The error JDK not found is coming from the replacement of the / by \ >>> in the JT_JAVA environment variable. In effect, the cygwin path >>> should be with "/" and not "\"... -- I know, it is a nightmare >>> --...hopefully,we will beat it! >>> >>> Francis >>> >>> Le 31/10/2013 02:41, Jonathan Gibbons a ?crit : >>>> Spurred on by the recent discussions and contributions, I've pushed >>>> some more changes to the jtreg repo to make it easier to build, and >>>> even run most of the tests, on Windows. >>>> >>>> (I still recommend using Linux instead, when that is an option.) >>>> >>>> The cygwin world is definitely problematic, especially for running >>>> the jtreg tests, since cygwin presents a different view of the file >>>> system to the native Windows view seen by Java programs. The >>>> problems mostly show up in tests that check that output from jtreg, >>>> especially when using diff, grep, etc. For the time being, I've >>>> disabled the tests in 11 of the 70 test files in make/tests/*.gmk, >>>> meaning that the tests in the remaining 59 files all run successfully. >>>> >>>> For what its worth, my setup is to have a cygwin symlink from /opt >>>> to C:/opt (i.e. /cygdrive/c/opt) which means that I can place all >>>> my dependencies in /opt//package///version/ and can then see them >>>> from both the cygwin world and the Windows world, without having to >>>> use path-munging utilities like cygpath all over the place. >>>> >>>> I'm open to more direct support of /cygdrive paths in the build, >>>> and wonder if folk have any good tips and tricks for minimising the >>>> obtrusiveness of the conversion functions in the composite world of >>>> GNU make and cygwin, such that the resulting code runs on Cygwin >>>> and POSIX systems. >>>> >>>> -- Jon >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20131101/0b3827a0/attachment-0001.html From mike.duigou at oracle.com Fri Nov 1 09:25:40 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 1 Nov 2013 09:25:40 -0700 Subject: building jtreg, and running tests In-Reply-To: <5273C917.1040400@oracle.com> References: <5271B563.7010301@oracle.com> <5272BD38.6090409@orange.fr> <527314A7.3040500@oracle.com> <5273C917.1040400@oracle.com> Message-ID: <27A2FD0E-2230-4FFF-867D-BEFBF3906D4D@oracle.com> On Nov 1 2013, at 08:30 , Jonathan Gibbons wrote: > On 10/31/2013 08:16 PM, Mike Duigou wrote: >>> Some folk may use jtreg by means of the various test targets in the various Makefiles. I don't know what the conventions are for accepting /cygdrive paths in the makefiles, or whether the mixed format is expected/required. Maybe someone more familiar with using those makefiles on Windows with Cygwin can comment. >> >> I have been working on the test/Makefiles and have been thinking where to properly make the split between native paths and cygwin paths. Currently it's done all in the makefile but perhaps in the jtreg script wrapper might be a better place (or more convenient) since it is going to get invoked anyway and will always be invoked from within a posix-like environment like either cygwin or mingw. This would also eliminate the need to have platform specific code in the test makefiles which would be nice. > > I was using the old JDK makefiles as a guideline/reference, where the methodology within the makefiles was to use mixed paths (drive letters plus "/"). There are comments from Kelly within the makefiles as to the rationale. It would be interesting to talk to the current build team about the methodology within the new build, and to follow their lead within the test makefiles. Yes, my plan is to try to match what they do as directly as possible. Some changes are currently impractical because the test makefiles don't (yet) import the spec.gmk or other utility makefiles so I can't transition them to using the same facilities. Official retirement of the old build will make it possible to use common code from the build infrastructure in the test makefiles. > >> >> Another option I have considered: Windows command scripts to replace or supplement the jtreg and jtdiff scripts that would be fully windows native. I'd like to consider eliminating the duplicate bin directories and going with a single bin directory like Ant does. > > I'm not sure what you mean here. By "fully windows native" do you mean a .BAT file? How does that go along with the use of a single bin directory? Yes, a .BAT file (or the slightly less obsolete .CMD script) is what I meant. In Ant and Maven there is a single bin directory with shell scripts, BAT files and even REXX and VMS scripts. > FWIW, I'd support going with a single bin directory; the duplicate directoris are a historical anachronism; the only reason I've held off is to avoid breaking infrastructure which assumes the existence of the extra path level. Maybe if enough systems use test/Makefile, we can paper over the transition in test/Makefile. Having the build scripts and test/Makefile hide the mechanics for most people is my goal. Mike > > -- Jon > >> >> Mike >> >> >>> >>> For another day: >>> >>> What about MSYS/MinGW? >>> If you want your head to explode, try reading http://www.mingw.org/wiki/Posix_path_conversion >>> >>> -- Jon >>> >>> >>> On 10/31/2013 01:27 PM, Francis ANDRE wrote: >>>> Hi Jon >>>> >>>> I run all the jdk8 test on WXP/Cygwin with your latest version of jtreg and found this problem: >>>> >>>> $ JT_JAVA=/cygdrive/Z/JDK/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image Z:/JDK/jt >>>> reg/build/images/jtreg/win32/bin/jtreg -J-Xmx512m -vmoption:-Xmx768m -a -ignore:quiet -v:fail,e >>>> rror,nopass -r:Z:/JDK/jdk8/LANGTO~1/build/WINDOW~1/test/LANGTO~1/jtreg/JTreport >>>> -w:Z:/JDK/jdk8/LANGTO~1/build/WINDOW~1/test/LANGTO~1/jtreg/JTwork -jdk:/cygdrive/Z/JDK/j >>>> dk8/build/windows-x86-normal-server-release/images/j2sdk-image -agentvm -concurrency:2 >>>> . || ( status=$?; if [ $status -ge 3 ]; then exit $status ; fi ; echo $status > Z:/ >>>> JDK/jdk8/LANGTO~1/build/WINDOW~1/test/LANGTO~1/jtreg/status.txt ) >>>> Error: JDK not found: \cygdrive\Z\JDK\jdk8\build\windows-x86-normal-server-release\images\j2sdk-imag >>>> e >>>> >>>> The error JDK not found is coming from the replacement of the / by \ in the JT_JAVA environment variable. In effect, the cygwin path should be with "/" and not "\"... -- I know, it is a nightmare --...hopefully,we will beat it! >>>> >>>> Francis >>>> >>>> Le 31/10/2013 02:41, Jonathan Gibbons a ?crit : >>>>> Spurred on by the recent discussions and contributions, I've pushed some more changes to the jtreg repo to make it easier to build, and even run most of the tests, on Windows. >>>>> >>>>> (I still recommend using Linux instead, when that is an option.) >>>>> >>>>> The cygwin world is definitely problematic, especially for running the jtreg tests, since cygwin presents a different view of the file system to the native Windows view seen by Java programs. The problems mostly show up in tests that check that output from jtreg, especially when using diff, grep, etc. For the time being, I've disabled the tests in 11 of the 70 test files in make/tests/*.gmk, meaning that the tests in the remaining 59 files all run successfully. >>>>> >>>>> For what its worth, my setup is to have a cygwin symlink from /opt to C:/opt (i.e. /cygdrive/c/opt) which means that I can place all my dependencies in /opt/package/version and can then see them from both the cygwin world and the Windows world, without having to use path-munging utilities like cygpath all over the place. >>>>> >>>>> I'm open to more direct support of /cygdrive paths in the build, and wonder if folk have any good tips and tricks for minimising the obtrusiveness of the conversion functions in the composite world of GNU make and cygwin, such that the resulting code runs on Cygwin and POSIX systems. >>>>> >>>>> -- Jon >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20131101/6514eb70/attachment.html From jonathan.gibbons at oracle.com Fri Nov 1 10:29:21 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 01 Nov 2013 10:29:21 -0700 Subject: building jtreg, and running tests In-Reply-To: <27A2FD0E-2230-4FFF-867D-BEFBF3906D4D@oracle.com> References: <5271B563.7010301@oracle.com> <5272BD38.6090409@orange.fr> <527314A7.3040500@oracle.com> <5273C917.1040400@oracle.com> <27A2FD0E-2230-4FFF-867D-BEFBF3906D4D@oracle.com> Message-ID: <5273E4F1.3030808@oracle.com> On 11/01/2013 09:25 AM, Mike Duigou wrote: > Yes, a .BAT file (or the slightly less obsolete .CMD script) is what I > meant. In Ant and Maven there is a single bin directory with shell > scripts, BAT files and even REXX and VMS scripts. Is there anyone out there who wants to volunteer to write a .BAT/.CMD file for jtreg, equivalent to the current *sh script? -- Jon From jonathan.gibbons at oracle.com Fri Nov 1 10:44:25 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 01 Nov 2013 10:44:25 -0700 Subject: building jtreg, and running tests In-Reply-To: <27A2FD0E-2230-4FFF-867D-BEFBF3906D4D@oracle.com> References: <5271B563.7010301@oracle.com> <5272BD38.6090409@orange.fr> <527314A7.3040500@oracle.com> <5273C917.1040400@oracle.com> <27A2FD0E-2230-4FFF-867D-BEFBF3906D4D@oracle.com> Message-ID: <5273E879.40806@oracle.com> On 11/01/2013 09:25 AM, Mike Duigou wrote: > >> FWIW, I'd support going with a single bin directory; the duplicate >> directoris are a historical anachronism; the only reason I've held >> off is to avoid breaking infrastructure which assumes the existence >> of the extra path level. Maybe if enough systems use test/Makefile, >> we can paper over the transition in test/Makefile. > > Having the build scripts and test/Makefile hide the mechanics for most > people is my goal. I've just checked -- the auto-detection for JT_HOME from the location of the jtreg script will work if we move to a single bin directory. What would it take to have the test/Makefiles able to tolerate a single or a duplicate bin directory? i.e. $JT_HOME/bin/jtreg or $JT_HOME/win32/bin/jtreg? -- Jon From Alan.Bateman at oracle.com Fri Nov 22 02:48:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Nov 2013 10:48:16 +0000 Subject: Number of agent VMs unbounded even when running with -concurrency:N ? Message-ID: <528F3670.5000401@oracle.com> Mike Duigou and I were chatting yesterday about the number of VMs that are might be in memory at a time when running in agentvm mode with -concurrency:N. We're not using -compilejdk so I think the starting answer is N+1 (the additional 1 because of jtreg itself). With the jdk tests then it gets complicated because there are some areas when the tests are configured to run in othervm mode, also there are many tests that spin up several VMs for the duration of the test. One point of discussion is we have different understanding on is what happens when a test is configured to run with a specific set of VM options. So suppose we are running with -concurrency:N and the agent pool has N agents already. If jtreg encounters a test with a completely new set of VM options then does it spin up a new VM (hence growing the pool to N+1) or does it close down one agent VM and spin up a new one? I skimmed through the jtreg code but it wasn't immediately obvious. Mike went one further and plotted the number of VMs that he sees on his system when running with -concurrency:11. His plots support his understanding that the number of VMs may be unbounded. -Alan. From jonathan.gibbons at oracle.com Mon Nov 25 17:33:45 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 25 Nov 2013 17:33:45 -0800 Subject: JTREG support for provider cleanup In-Reply-To: <5293B1C9.1000003@oracle.com> References: <5293B1C9.1000003@oracle.com> Message-ID: <5293FA79.2040702@oracle.com> Rajan, There is a recent RFE for this, which has not yet been implemented. For now, you either have to do the cleanup yourself, or mark the test to run in othervm mode. -- Jon On 11/25/2013 12:23 PM, Rajan Halade wrote: > Hi All, > > I browsed through jtreg documentation but couldn't find any support > for security provider cleanup after test execution. Is the support > there today? I appreciate any feedback in this regard. > > *Some Background:* > The problem is that when test run in agentvm mode that updates > security providers, it can cause adverse effects on next tests > executed in same batch. We had few intermittent test failures in the > past because of this issue. > > Refer to email thread [1] where we are discussing this issue and > possible approach. We considered changing such tests to use othervm > option but before that would like to see if jtreg provides/can provide > any option to help with this one. > > [1] > http://mail.openjdk.java.net/pipermail/security-dev/2013-November/009744.html > [2] https://bugs.openjdk.java.net/browse/JDK-8027598 > > Thanks, > Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20131125/ce121a88/attachment.html From rajan.halade at oracle.com Mon Nov 25 20:24:13 2013 From: rajan.halade at oracle.com (Rajan Halade) Date: Mon, 25 Nov 2013 20:24:13 -0000 Subject: JTREG support for provider cleanup Message-ID: <5293B1C9.1000003@oracle.com> Hi All, I browsed through jtreg documentation but couldn't find any support for security provider cleanup after test execution. Is the support there today? I appreciate any feedback in this regard. *Some Background:* The problem is that when test run in agentvm mode that updates security providers, it can cause adverse effects on next tests executed in same batch. We had few intermittent test failures in the past because of this issue. Refer to email thread [1] where we are discussing this issue and possible approach. We considered changing such tests to use othervm option but before that would like to see if jtreg provides/can provide any option to help with this one. [1] http://mail.openjdk.java.net/pipermail/security-dev/2013-November/009744.html [2] https://bugs.openjdk.java.net/browse/JDK-8027598 Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: