RFR: 8163014: Mysterious/wrong value for "long" frame local variable on 64-bit

[Coleen Phillimore]

Max,

http://cr.openjdk.java.net/~mockner/8163014.01/test/runtime/locallong/LocalLongHelper.java.html

There's a lot in this test, but I can't think of a different way to 
inspect the stack to find out if the long unused slot is zeroed. This 
file is missing a copyright, and I think the directory should be 
LocalLong (I think our new convention of test directory names is 
capitalized).  I think we should keep the test in the hotspot repository 
even though it uses the StackWalk API because otherwise it won't be run 
with hotspot changes on an ad-hoc or nightly basis.

http://cr.openjdk.java.net/~mockner/8163014.01/test/runtime/locallong/LocalLongTest.java.html

I thought the idea was to run this with -Xint not -Xcomp?

The interpreter changes look good.

Coleen

On 9/6/16 5:33 PM, Max Ockner wrote:
> Hello,
> Please review this multi-platform fix for the stack walk API.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163014
> Webrev: http://cr.openjdk.java.net/~mockner/8163014.01/
>
> In 64 bits, long values can fit into a single slot, but two slots are 
> still used. The high slot contains garbage. This normally wouldn't 
> matter since it is never read from but the stack walk API expects to 
> display useful information. This is an issue when displaying longs 
> from local variables, so this means we can kill any garbage off by 
> zeroing it when it is pushed to the stack in the previous frame. This 
> solution zeroes the high byte of a long value when it is being pushed 
> to the stack (in push_l).
>
> This applies to x86, aarch64, and sparc. This change does not apply to 
> ppc, though the bug almost certainly does affect it. I have left ppc 
> untouched since I don't have access to the hardware required to 
> reproduce the bug and test the fix.
>
> I have adapted the reproducer from the bug into a test. It is curently 
> sitting in runtime/locallong, but I believe there must be a better 
> place for it.
>
> Thanks,
> Max