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.daughe...@oracle.com
To: staffan.lar...@oracle.com, alexander.kulyakh...@oracle.com
Cc: serviceability-dev@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.kulyakh...@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.lar...@oracle.com
To: alexander.kulyakh...@oracle.com
Cc: serviceability-dev@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.kulyakh...@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
