RFR: 8163014: Mysterious/wrong value for "long" frame local variable on 64-bit
max.ockner at oracle.com
Thu Sep 8 16:26:46 UTC 2016
Here is version 2 of this fix.
- Added copyright to LocalLongHelper.java
- Switched LocalLongTest.java to run with -Xint instead of -Xcomp, and
cleaned up some copypaste garbage.
- changed the test directory name from locallong to LocalLong.
Reran test with -Xint.
On 9/7/2016 9:47 AM, Coleen Phillimore wrote:
> 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.
> I thought the idea was to run this with -Xint not -Xcomp?
> The interpreter changes look good.
> On 9/6/16 5:33 PM, Max Ockner wrote:
>> 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.
More information about the hotspot-runtime-dev