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

[Coleen Phillimore]

On 9/7/16 9:09 AM, Max Ockner wrote:
> Does the stackwalk API have access to the type of variable at each 
> slot? Where is this information stored? My operating assumption was 
> that it did not have this information, and therefore needed to read 
> the garbage slot.

This is true.  The StackWalk API does not have type information for 
these longs, so this prevents garbage values from being read.
Adding core-libs.

Thanks,
Coleen

> Max
>
> On 9/6/2016 8:24 PM, dean.long at oracle.com wrote:
>> Instead of fixing this at write time, how about instead fixing it at 
>> read time?  That was my understanding of John's comment:
>>
>> A virtualized API which
>> produces a view on such an L[1] needs to return some
>> default value (if pressed), and to indicate that the slot
>> has no payload.
>>
>> SoLiveStackFrame.getLocals() would never read the physical garbage 
>> slot, but instead would act as if it
>> read 0 instead.  And by LiveStackFrame.getLocals() I really mean 
>> whatever code fills in its "locals" field,
>> which I guess is the JVM.
>>
>> dl
>>
>> On 9/6/16 2: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 
>