From david.holmes at oracle.com Fri Jul 6 02:02:12 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 Jul 2018 12:02:12 +1000 Subject: System.out versus stdout output order Message-ID: <9d7bb6e3-f643-aa44-7933-786e3332bab7@oracle.com> I have a Java test that calls a native method with uses printf (in a second thread which is started and joined by the original method), and then the subsequent Java code uses System.out. What I see in the .jtr file is that the C printf output always comes after the System.out output, even though the code in question had to be executed before it. Is this just some quirk of how jtreg collects process output for logging? Thanks, David From Roger.Riggs at Oracle.com Fri Jul 6 13:44:37 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 6 Jul 2018 09:44:37 -0400 Subject: System.out versus stdout output order In-Reply-To: <9d7bb6e3-f643-aa44-7933-786e3332bab7@oracle.com> References: <9d7bb6e3-f643-aa44-7933-786e3332bab7@oracle.com> Message-ID: Hi David, stdout and system.out are buffered, so you might need to look at when/if flush is called. $.02, Roger On 7/5/2018 10:02 PM, David Holmes wrote: > I have a Java test that calls a native method with uses printf (in a > second thread which is started and joined by the original method), and > then the subsequent Java code uses System.out. What I see in the .jtr > file is that the C printf output always comes after the System.out > output, even though the code in question had to be executed before it. > Is this just some quirk of how jtreg collects process output for logging? > > Thanks, > David From martinrb at google.com Fri Jul 6 14:55:29 2018 From: martinrb at google.com (Martin Buchholz) Date: Fri, 6 Jul 2018 07:55:29 -0700 Subject: System.out versus stdout output order In-Reply-To: References: <9d7bb6e3-f643-aa44-7933-786e3332bab7@oracle.com> Message-ID: On Fri, Jul 6, 2018 at 6:44 AM, Roger Riggs wrote: > Hi David, > > stdout and system.out are buffered, so you might need to look at when/if > flush is called. > More to the point, they use independent buffers. See also Java Puzzler 81 Charred Beyond Recognition https://books.google.com/books?id=RM9sLE0ntQ0C&pg=RA1-PT231&dq=Java+Puzzler+81+Charred+Beyond+Recognition&hl=en&sa=X&ved=0ahUKEwiboLSw3YrcAhXIslQKHZeVDtcQ6AEIKTAA#v=onepage&q=Java%20Puzzler%2081%20Charred%20Beyond%20Recognition&f=false -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Jul 9 02:05:52 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 9 Jul 2018 12:05:52 +1000 Subject: System.out versus stdout output order In-Reply-To: References: <9d7bb6e3-f643-aa44-7933-786e3332bab7@oracle.com> Message-ID: Hi Martin, Roger, On 7/07/2018 12:55 AM, Martin Buchholz wrote: > > > On Fri, Jul 6, 2018 at 6:44 AM, Roger Riggs > wrote: > > Hi David, > > stdout and system.out are buffered, so you might need to look at > when/if flush is called. Newlines trigger flushing and that occurs in both cases. > More to the point, they use independent buffers. > See also Java Puzzler 81 Charred Beyond Recognition > https://books.google.com/books?id=RM9sLE0ntQ0C&pg=RA1-PT231&dq=Java+Puzzler+81+Charred+Beyond+Recognition&hl=en&sa=X&ved=0ahUKEwiboLSw3YrcAhXIslQKHZeVDtcQ6AEIKTAA#v=onepage&q=Java%20Puzzler%2081%20Charred%20Beyond%20Recognition&f=false I can't see the solution to Puzzler 81 but am assuming it just relates to buffering. I can't see how it relates to "independent buffers" ?? AFAIK System.out is connected to stdout for the process, and C printf also writes to stdout, hence I would have expected, in the normal case that I would see the output in the correct temporal order. And indeed when run directly that is the case: /export/users/dh198349/jdk11/open/test/hotspot/jtreg > ../../../../build/linux-x64-debug/images/jdk/bin/java -cp ./JTwork/classes/runtime/jni/terminatedThread/TestTerminatedThread.d/ -Djava.library.path=/export/users/dh198349/jdk11/build/linux-x64-debug/images/test/hotspot/jtreg/native/ TestTerminatedThread Native thread is running and attaching as daemon ... Native thread terminating Working with thread: Thread[Thread-0,5,main], in state: RUNNABLE Calling suspend ... Calling resume ... Calling getStackTrace ... ... So the difference is with how jtreg is intercepting/redirecting the different streams from the process. Not a problem, just something I noticed and wanted to double-check. Cheers, David From martinrb at google.com Mon Jul 9 16:53:56 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 9 Jul 2018 09:53:56 -0700 Subject: System.out versus stdout output order In-Reply-To: References: <9d7bb6e3-f643-aa44-7933-786e3332bab7@oracle.com> Message-ID: Ahhh, OK, jtreg is using System.setOut(out); which is how the java and C++ output ends up in different destinations. So yes, nothing to do with buffering. I'll update my internal mental model of how jtreg works. It would be nice if jtreg could capture both together, but that might take a lot of non-java plumbing. On Sun, Jul 8, 2018 at 7:05 PM, David Holmes wrote: > Hi Martin, Roger, > > On 7/07/2018 12:55 AM, Martin Buchholz wrote: > >> >> >> On Fri, Jul 6, 2018 at 6:44 AM, Roger Riggs > > wrote: >> >> Hi David, >> >> stdout and system.out are buffered, so you might need to look at >> when/if flush is called. >> > > Newlines trigger flushing and that occurs in both cases. > > More to the point, they use independent buffers. >> See also Java Puzzler 81 Charred Beyond Recognition >> https://books.google.com/books?id=RM9sLE0ntQ0C&pg=RA1-PT231& >> dq=Java+Puzzler+81+Charred+Beyond+Recognition&hl=en&sa=X& >> ved=0ahUKEwiboLSw3YrcAhXIslQKHZeVDtcQ6AEIKTAA#v=onepage&q= >> Java%20Puzzler%2081%20Charred%20Beyond%20Recognition&f=false >> > > I can't see the solution to Puzzler 81 but am assuming it just relates to > buffering. I can't see how it relates to "independent buffers" ?? > > AFAIK System.out is connected to stdout for the process, and C printf also > writes to stdout, hence I would have expected, in the normal case that I > would see the output in the correct temporal order. And indeed when run > directly that is the case: > > /export/users/dh198349/jdk11/open/test/hotspot/jtreg > > ../../../../build/linux-x64-debug/images/jdk/bin/java -cp > ./JTwork/classes/runtime/jni/terminatedThread/TestTerminatedThread.d/ > -Djava.library.path=/export/users/dh198349/jdk11/build/linux > -x64-debug/images/test/hotspot/jtreg/native/ TestTerminatedThread > Native thread is running and attaching as daemon ... > Native thread terminating > Working with thread: Thread[Thread-0,5,main], in state: RUNNABLE > Calling suspend ... > Calling resume ... > Calling getStackTrace ... > ... > > So the difference is with how jtreg is intercepting/redirecting the > different streams from the process. > > Not a problem, just something I noticed and wanted to double-check. > > Cheers, > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Jul 11 07:34:32 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 11 Jul 2018 09:34:32 +0200 Subject: [11] RFR(S): 8206998: [test] runtime/ElfDecoder/TestElfDirectRead.java requires longer timeout on ppc64 In-Reply-To: <578bb78a-8d62-ebd9-84e7-8ce37da77fbe@oracle.com> References: <578bb78a-8d62-ebd9-84e7-8ce37da77fbe@oracle.com> Message-ID: Hi David, so it obviously works and as Goetz mentioned there are already other, existing tests which use this feature. Do you want me to get a formal review which confirms this from somebody from the JTreg team? I've CC-ed jtreg-use and Jonathan in the hope that they can confirm this. Regards, Volker On Tue, Jul 10, 2018 at 11:24 PM, David Holmes wrote: > Hi Volker, > > On 11/07/2018 3:52 AM, Volker Simonis wrote: >> >> Hi, >> >> can I please get a review for the following test-only change: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8206998/ >> https://bugs.openjdk.java.net/browse/JDK-8206998 >> >> The problem is that the test runtime/ElfDecoder/TestElfDirectRead.java >> intentionally disables caching of Elf sections during symbol lookup >> with WhiteBox.disableElfSectionCache(). On platforms which do not use >> file descriptors instead of plain function pointers this slows down >> the lookup just a little bit, because all the symbols from an Elf file >> are still read consecutively after one 'fseek()' call. But on >> platforms with file descriptors like ppc64 big-endian, we get two >> 'fseek()' calls for each symbol read from the Elf file because reading >> the file descriptor table is nested inside the loop which reads the >> symbols. This really trashes the I/O system and considerable slows >> down the test, so we need an extra long timeout setting. >> >> The fix is trivial - simply provide two test versions (i.e. comments): >> the first one for all Linux flavors which are not ppc64 and a second, >> new one for Linux/ppc64 which simply has a bigger timeout. > > > I was not aware that this was a valid way of defining a test! This suggests > there can only be one "leading comment" per "defining file: > > http://openjdk.java.net/jtreg/tag-spec.html > > Need to verify this with the jtreg folk: jtreg-use at openjdk.java.net > > Thanks, > David > > >> Thank you and best regards, >> Volker >> > From david.holmes at oracle.com Wed Jul 11 07:41:54 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Jul 2018 17:41:54 +1000 Subject: [11] RFR(S): 8206998: [test] runtime/ElfDecoder/TestElfDirectRead.java requires longer timeout on ppc64 In-Reply-To: References: <578bb78a-8d62-ebd9-84e7-8ce37da77fbe@oracle.com> Message-ID: <5ffa742c-d0eb-f94b-448a-dd45674b334a@oracle.com> Hi Volker, On 11/07/2018 5:34 PM, Volker Simonis wrote: > Hi David, > > so it obviously works and as Goetz mentioned there are already other, > existing tests which use this feature. > > Do you want me to get a formal review which confirms this from > somebody from the JTreg team? > > I've CC-ed jtreg-use and Jonathan in the hope that they can confirm this. No that's fine - just surprised to see this (and couldn't find any documentation for it!). Thanks, David > Regards, > Volker > > On Tue, Jul 10, 2018 at 11:24 PM, David Holmes wrote: >> Hi Volker, >> >> On 11/07/2018 3:52 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> can I please get a review for the following test-only change: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8206998/ >>> https://bugs.openjdk.java.net/browse/JDK-8206998 >>> >>> The problem is that the test runtime/ElfDecoder/TestElfDirectRead.java >>> intentionally disables caching of Elf sections during symbol lookup >>> with WhiteBox.disableElfSectionCache(). On platforms which do not use >>> file descriptors instead of plain function pointers this slows down >>> the lookup just a little bit, because all the symbols from an Elf file >>> are still read consecutively after one 'fseek()' call. But on >>> platforms with file descriptors like ppc64 big-endian, we get two >>> 'fseek()' calls for each symbol read from the Elf file because reading >>> the file descriptor table is nested inside the loop which reads the >>> symbols. This really trashes the I/O system and considerable slows >>> down the test, so we need an extra long timeout setting. >>> >>> The fix is trivial - simply provide two test versions (i.e. comments): >>> the first one for all Linux flavors which are not ppc64 and a second, >>> new one for Linux/ppc64 which simply has a bigger timeout. >> >> >> I was not aware that this was a valid way of defining a test! This suggests >> there can only be one "leading comment" per "defining file: >> >> http://openjdk.java.net/jtreg/tag-spec.html >> >> Need to verify this with the jtreg folk: jtreg-use at openjdk.java.net >> >> Thanks, >> David >> >> >>> Thank you and best regards, >>> Volker >>> >> From jonathan.gibbons at oracle.com Mon Jul 23 21:48:10 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 23 Jul 2018 14:48:10 -0700 Subject: [11] RFR(S): 8206998: [test] runtime/ElfDecoder/TestElfDirectRead.java requires longer timeout on ppc64 In-Reply-To: References: <578bb78a-8d62-ebd9-84e7-8ce37da77fbe@oracle.com> Message-ID: <4e671fef-bcc5-0508-b734-befe1d1686b4@oracle.com> Volker, Sorry I missed this before my recent vacation. Yes, it is now "officially" supported that you can have multiple test descriptions (comment blocks beginning '@test'). Since forever, it was unofficially allowed but not well integrated as a feature. This was fixed a while back: 7901940: support multiple @test in one test file The issue which needed to be fixed was in the naming of the individual tests within the file, such that you could distinguish the individual tests from the overall collection of tests in the file. -- Jon On 7/11/18 12:34 AM, Volker Simonis wrote: > Hi David, > > so it obviously works and as Goetz mentioned there are already other, > existing tests which use this feature. > > Do you want me to get a formal review which confirms this from > somebody from the JTreg team? > > I've CC-ed jtreg-use and Jonathan in the hope that they can confirm this. > > Regards, > Volker > > On Tue, Jul 10, 2018 at 11:24 PM, David Holmes wrote: >> Hi Volker, >> >> On 11/07/2018 3:52 AM, Volker Simonis wrote: >>> Hi, >>> >>> can I please get a review for the following test-only change: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8206998/ >>> https://bugs.openjdk.java.net/browse/JDK-8206998 >>> >>> The problem is that the test runtime/ElfDecoder/TestElfDirectRead.java >>> intentionally disables caching of Elf sections during symbol lookup >>> with WhiteBox.disableElfSectionCache(). On platforms which do not use >>> file descriptors instead of plain function pointers this slows down >>> the lookup just a little bit, because all the symbols from an Elf file >>> are still read consecutively after one 'fseek()' call. But on >>> platforms with file descriptors like ppc64 big-endian, we get two >>> 'fseek()' calls for each symbol read from the Elf file because reading >>> the file descriptor table is nested inside the loop which reads the >>> symbols. This really trashes the I/O system and considerable slows >>> down the test, so we need an extra long timeout setting. >>> >>> The fix is trivial - simply provide two test versions (i.e. comments): >>> the first one for all Linux flavors which are not ppc64 and a second, >>> new one for Linux/ppc64 which simply has a bigger timeout. >> >> I was not aware that this was a valid way of defining a test! This suggests >> there can only be one "leading comment" per "defining file: >> >> http://openjdk.java.net/jtreg/tag-spec.html >> >> Need to verify this with the jtreg folk: jtreg-use at openjdk.java.net >> >> Thanks, >> David >> >> >>> Thank you and best regards, >>> Volker >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue Jul 24 07:29:23 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 24 Jul 2018 09:29:23 +0200 Subject: [11] RFR(S): 8206998: [test] runtime/ElfDecoder/TestElfDirectRead.java requires longer timeout on ppc64 In-Reply-To: <4e671fef-bcc5-0508-b734-befe1d1686b4@oracle.com> References: <578bb78a-8d62-ebd9-84e7-8ce37da77fbe@oracle.com> <4e671fef-bcc5-0508-b734-befe1d1686b4@oracle.com> Message-ID: Hi Jonathan, thanks for following up on this issue. Would it be possible to also update the corresponding documentation [1] ? It still has the following information which is simply wrong now: INFORMATIONAL TAGS ... @test * Defining-file identifier; * is typically SCCS identification info ... Any particular informational tag, except the @comment tag, may occur at most once in a given test. The @comment tag may be used multiple times. Thank you and best regards, Volker [1] http://openjdk.java.net/jtreg/tag-spec.html On Mon, Jul 23, 2018 at 11:48 PM, Jonathan Gibbons wrote: > Volker, > > Sorry I missed this before my recent vacation. > > Yes, it is now "officially" supported that you can have multiple test > descriptions (comment blocks beginning '@test'). > > Since forever, it was unofficially allowed but not well integrated as a > feature. This was fixed a while back: > > 7901940: support multiple @test in one test file > > The issue which needed to be fixed was in the naming of the individual tests > within the file, such that you could distinguish the individual tests from > the overall collection of tests in the file. > > -- Jon > > > On 7/11/18 12:34 AM, Volker Simonis wrote: > > Hi David, > > so it obviously works and as Goetz mentioned there are already other, > existing tests which use this feature. > > Do you want me to get a formal review which confirms this from > somebody from the JTreg team? > > I've CC-ed jtreg-use and Jonathan in the hope that they can confirm this. > > Regards, > Volker > > On Tue, Jul 10, 2018 at 11:24 PM, David Holmes > wrote: > > Hi Volker, > > On 11/07/2018 3:52 AM, Volker Simonis wrote: > > Hi, > > can I please get a review for the following test-only change: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8206998/ > https://bugs.openjdk.java.net/browse/JDK-8206998 > > The problem is that the test runtime/ElfDecoder/TestElfDirectRead.java > intentionally disables caching of Elf sections during symbol lookup > with WhiteBox.disableElfSectionCache(). On platforms which do not use > file descriptors instead of plain function pointers this slows down > the lookup just a little bit, because all the symbols from an Elf file > are still read consecutively after one 'fseek()' call. But on > platforms with file descriptors like ppc64 big-endian, we get two > 'fseek()' calls for each symbol read from the Elf file because reading > the file descriptor table is nested inside the loop which reads the > symbols. This really trashes the I/O system and considerable slows > down the test, so we need an extra long timeout setting. > > The fix is trivial - simply provide two test versions (i.e. comments): > the first one for all Linux flavors which are not ppc64 and a second, > new one for Linux/ppc64 which simply has a bigger timeout. > > I was not aware that this was a valid way of defining a test! This suggests > there can only be one "leading comment" per "defining file: > > http://openjdk.java.net/jtreg/tag-spec.html > > Need to verify this with the jtreg folk: jtreg-use at openjdk.java.net > > Thanks, > David > > > Thank you and best regards, > Volker > > From prasanta.sadhukhan at oracle.com Thu Jul 26 10:10:41 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 26 Jul 2018 15:40:41 +0530 Subject: jtreg 42b12 build 398 fails on macos10.13 running jdk12 test Message-ID: Hi, I am trying to run jdk12 regression test case with jtreg42b12 b398 but encountering an error on osx10.13.3. Can anyone point what needs to be done? #./bin/jtreg -jdk:/Users/PRSADHUK/Downloads/jdk-11.jdk/Contents/Home/ /export/jdk/client/closed/test/jdk/java/awt/Frame/Undecorated/MinimizeUndecoratedTest/MinimizeUndecoratedTest.html Directory "JTwork" not found: creating Directory "JTreport" not found: creating Exception in thread "main" java.lang.UnsatisfiedLinkError: sun.hotspot.WhiteBox.isJavaHeapArchiveSupported()Z at sun.hotspot.WhiteBox.isJavaHeapArchiveSupported(Native Method) at requires.VMProps.vmCDSForArchivedJavaHeap(VMProps.java:366) at requires.VMProps.call(VMProps.java:89) at requires.VMProps.call(VMProps.java:55) at com.sun.javatest.regtest.agent.GetJDKProperties.run(GetJDKProperties.java:66) at com.sun.javatest.regtest.agent.GetJDKProperties.main(GetJDKProperties.java:46) Error: failed to get JDK properties for /Users/PRSADHUK/Downloads/jdk-11.jdk/Contents/Home/bin/ #./bin/jtreg -version jtreg, version 4.2 dev 398 Installed in /Users/PRSADHUK/Downloads/jtreg/lib/jtreg.jar Running on platform version 10.0.2 from /Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home. Built with Java(TM) 2 SDK, Version 1.8.0_121-b13 on June 11, 2018. Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. JTHarness: version 5.0 JCov 3.0-2 TestNG (testng.jar): version unknown TestNG (jcommander.jar): version 1.72 AsmTools: version 7.0 ; exit code 1 Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Thu Jul 26 15:45:38 2018 From: martinrb at google.com (Martin Buchholz) Date: Thu, 26 Jul 2018 08:45:38 -0700 Subject: jtreg support for --patch-module? In-Reply-To: <7c480628-5f3f-4da5-9242-105aa0f05358@Oracle.com> References: <7c480628-5f3f-4da5-9242-105aa0f05358@Oracle.com> Message-ID: Hej Roger, I don't know what would be the canonical example, but many tests do this. Look for such tests by finding partial java.base trees: ~/ws/jdk/test $ find -name java | grep java.base/java ./jdk/java/util/stream/boottest/java.base/java ./jdk/java/lang/instrument/java.base/java ./jdk/java/lang/invoke/lookup/java.base/java ./jdk/java/lang/invoke/java.base/java ... On Fri, Aug 25, 2017 at 12:17 PM, Roger Riggs wrote: > Hi, > > For a test, I need to patch a class in a module. > I'm stumped on the correct series of @library, @build and @run setup to > see it automatically > pass the --patch-module options to javac and java. > > Am I expecting too much and have to revert to explicitly spawning the > compile and run steps? > > Thanks, Roger > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Jul 26 15:51:57 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 26 Jul 2018 08:51:57 -0700 Subject: jtreg support for --patch-module In-Reply-To: References: <7c480628-5f3f-4da5-9242-105aa0f05358@Oracle.com> Message-ID: Ooops, thanks. Will fix. -- Jon On 8/25/17 1:46 PM, Martin Buchholz wrote: > (yes, but the jtreg tag spec need updating from -Xmodule => > --patch-module) > > On Fri, Aug 25, 2017 at 12:40 PM, Roger Riggs > wrote: > > Never mind, I found > > @compile/module=xxx > > An @library is not needed > > Regards, Roger > > [1] http://openjdk.java.net/jtreg/tag-spec.html > > > > On 8/25/2017 3:17 PM, Roger Riggs wrote: > > Hi, > > For a test, I need to patch a class in a module. > I'm stumped on the correct series of @library, @build and @run > setup to see it automatically > pass the --patch-module options to javac and java. > > Am I expecting too much and have to revert to explicitly > spawning the compile and run steps? > > Thanks, Roger > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: