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
