New jtreg test about StackWalker's JDK-8147039 and JDK-8156073: qword decoding from frame locals

[Fabio Tudone (fabio@paralleluniverse.co)]

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