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

dean.long at oracle.com dean.long at oracle.com
Wed Sep 7 00:24:59 UTC 2016


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 


More information about the hotspot-runtime-dev mailing list