RFR (XS) 8015265: revise the fix for 8007037
Daniel D. Daugherty
daniel.daugherty at oracle.com
Thu May 23 13:20:10 PDT 2013
> webrev: http://cr.openjdk.java.net/~ccheung/8015265/webrev/
src/share/vm/oops/constantPool.cpp
Please add a comment like this before line 1066:
// separate statements and variables because CHECK_false is
used here:
1066 bool match_entry = compare_entry_to(k1, cp2, k2, CHECK_false);
1067 bool match_operand = compare_operand_to(i1, cp2, i2, CHECK_false);
Hopefully, this will prevent someone from 'optimizing' this logic
in the future.
> Testing:
> jprt
> vm.quick on linux_x64
This is a pretty straight forward fix so I'm OK with a single platform
vm.quick run, but it would be really good to have a regression test
for this issue since it was found by code inspection.
Dan
On 5/23/13 12:51 PM, Calvin Cheung wrote:
> While working on a fix for 8014431, it was found that the fix for
> 8007037 in constantPool.cpp needs to be revised. David H. suggested
> that this should be addressed in a separate bug fix.
>
> The problem is that the following statement:
> bool match = compare_entry_to(k1, cp2, k2, CHECK_false) &&
> compare_operand_to(i1, cp2, i2, CHECK_false);
>
> expands to:
>
> bool match = compare_entry_to(k1, cp2, k2, THREAD);
> if (HAS_PENDING_EXCEPTION) return false;
> (0) && compare_operand_to(i1, cp2, i2, THREAD);
> if (HAS_PENDING_EXCEPTION) return false;
> (0);
>
> so the match has the wrong value.
>
> webrev: http://cr.openjdk.java.net/~ccheung/8015265/webrev/
> bug: http://bugs.sun.com/view_bug.do?bug_id=8015265 (not available
> yet)
> jbs: https://jbs.oracle.com/bugs/browse/JDK-8015265
>
> Testing:
> jprt
> vm.quick on linux_x64
>
> thanks,
> Calvin
More information about the hotspot-runtime-dev
mailing list