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