Hi Staffan, I've changed the test fix for https://bugs.openjdk.java.net/browse/JDK-8147447 "serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails"
Webrev: http://cr.openjdk.java.net/~akulyakh/8147447_3/index.html Before the fix the test always tries to find and verify the object reference information in the jstack output. However, depending on the VM options, this information is not always available With the fix the test does not try to verify the object reference if it's not available. To keep the test simple we do not analyze if the object reference shall be available or not. Best regards, Alexander ----- Original Message ----- From: [email protected] To: [email protected] Cc: [email protected], [email protected], [email protected] Sent: Friday, January 22, 2016 1:28:12 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8147447: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails Hi Staffan, Following your suggestion below, I'm going to restrict the possible options for the test to -Xmixed only and verify that either of the two patterns is present in the jstack output. I'm going to submit a review after testing with all the options combinations. Best regards, Alexander ----- Original Message ----- From: [email protected] To: [email protected] Cc: [email protected], [email protected] Sent: Thursday, January 21, 2016 7:35:46 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8147447: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails > On 21 jan. 2016, at 16:52, Alexander Kulyakhtin > <[email protected]> wrote: > > Dan, > > Thank you very much for your help. > > I'm then going to modify the test accordingly. > In the -Xmixed mode the test will try to match the jstack output to both the > frames patterns and will succeed if either of them matches. > In the -Xint and -Xcomp mode the test will match to the corresponding pattern > as you have indicated > > In case the test is executed with several of those three options specified > together on the command line, the test will presume the option specified last > takes precedence. I think it would be fine to always assume -Xmixed mode and succeed if any of the frames matches. It would make the code simpler and easier to maintain. /Staffan > > Please, let me know if I'm missing something. > > Best regards, > Alexandr > > ----- Original Message ----- > From: [email protected] > To: [email protected], [email protected] > Cc: [email protected] > Sent: Thursday, January 21, 2016 6:35:47 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8147447: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails > > On 1/21/16 8:11 AM, Staffan Larsen wrote: >>> On 21 jan. 2016, at 15:33, Alexander Kulyakhtin >>> <[email protected]> wrote: >>> >>> Staffan, >>> >>> Would it be sufficient to modify the code so that isCompMode() returns true >>> if and only if the -Xcomp option is present and is not followed by the >>> -Xmixed option? >> Maybe, but that looks fragile. What if there is another option that >> implicitly enables compile mode? > > Even if the VM is in -Xmixed mode, code could get compiled and > the stack trace output would show the compiled frame version > and not the interpreted frame version. So: > > -Xint mode - the compiled frame version will not be seen > -Xmixed mode - both versions may be seen depending on compile > thresholds and other factors > -Xcomp mode - the compiled frame version will be seen > > Dan > > >> >>> Best regards, >>> Alexander >>> >>> ----- Original Message ----- >>> From: [email protected] >>> To: [email protected] >>> Cc: [email protected] >>> Sent: Thursday, January 21, 2016 5:20:14 PM GMT +03:00 Iraq >>> Subject: Re: RFR: JDK-8147447: [TESTBUG] >>> serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails >>> >>> isCompMode() will fail if the VM is started with both -Xcomp and -Xmixed. >>> >>> We need to find a better way to check if compiled mode is being used. >>> Perhaps System.getProperty("java.vm.info").contains("compiled”) ? >>> >>> /Staffan >>> >>>> On 19 jan. 2016, at 11:59, Alexander Kulyakhtin >>>> <[email protected]> wrote: >>>> >>>> Hi, >>>> >>>> Could you, please, review this minor test-only change >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8147447 "[TESTBUG] >>>> serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails" >>>> Webrev: http://cr.openjdk.java.net/~akulyakh/8147447/index.html >>>> >>>> The test WaitNotifyThreadTest.java tries expects to find in the jstack >>>> output the string similar to: >>>> 'waiting on <0x000000008f64e6d0> (a java.lang.Object)' >>>> However, with the -Xcomp option turned on there is no object reference >>>> available and the same strings look like: >>>> 'waiting on <no object reference available>' >>>> This causes the false failures of the test when executed with the -Xcomp >>>> option. >>>> >>>> We are modifying the test so it takes into account the possible difference >>>> between the jstack outputs. >>>> >>>> The same issue has been present in the legacy test from which this test >>>> has been ported, so it is not a new and not a regression issue. >>>> >>>> Best regards, >>>> Alexander >
