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>
