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

[Max Ockner]

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.
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