Hi,
I'm attaching an updated test: now it also perform assertions about
stack operands (they seem to behave like locals). I also converted it to
"testng/othervm" with a data provider for several "StackWalker" option
combinations.
Thanks,
-- Fabio Tudone
On 06/07/2016 05:18 AM, Mandy Chung wrote:
Hi Fabio,
Thanks for contributing the test. I created a JBS issue for this new
regression test:
https://bugs.openjdk.java.net/browse/JDK-8158879
We will look into JDK-8156073 before including this regression test.
Mandy
On Jun 6, 2016, at 3:06 PM, Fabio Tudone (fa...@paralleluniverse.co)
<fa...@paralleluniverse.co> wrote:
Hi,
I'd like to contribute a jtreg test (attached) that highlights StackWalker issues about decoding
qword (i.e. "long" and "double") frame locals and being able to read frame
locals consistently in every situation, in particular regardless of the execution mode.
The test is a single Java file that can be put in the "jdk/test/java/lang/StackWalker" directory of the full OpenJDK
tree and run as usual; it includes three "@run" tags for the "-Xcomp", "-Xcomp
-XX:-TieredCompilation" and "-Xint" JVM flag sets respectively.
Every execution mode fails the test for different reasons with JDK9 sources as of June
3th, 15:39 GMT (changeset 2098:3bff27179e47): you can read the test's stderr up to the
failing assertion by changing the "@run" tag ordering.
In particular, during the "-Xint" run the test can find but not decode the "long" local nor the "double" one; during the
"-Xcomp -XX:-TieredCompilation" and "-Xcomp" runs instead, the relevant dword slots have type "I" and value "0" if the
corresponding locals are unused in the method body and instead they have a value when used but only the "long" local can be decoded.
I have already signed the OCA.
Thanks and regards,
-- Fabio Tudone
<LongAndDoubleDecodingTest.java>
