RFR: JDK-8147447: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails

[Daniel D. Daugherty]

On 1/21/16 8:52 AM, Alexander Kulyakhtin 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.

The VM generally follows the "last option wins" rule.

Dan


>
> Please, let me know if I'm missing something.
>
> Best regards,
> Alexandr
>
> ----- Original Message -----
> From: daniel.daugherty at oracle.com
> To: staffan.larsen at oracle.com, alexander.kulyakhtin at oracle.com
> Cc: serviceability-dev at openjdk.java.net
> 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 <alexander.kulyakhtin at oracle.com> 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: staffan.larsen at oracle.com
>>> To: alexander.kulyakhtin at oracle.com
>>> Cc: serviceability-dev at openjdk.java.net
>>> 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 <alexander.kulyakhtin at oracle.com> 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