RFR 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::,compare_entry_to and copy_entry_to

Ioi Lam ioi.lam at oracle.com
Wed Oct 9 22:30:19 PDT 2013


Coleen,

I would suggest adding these sanity checks:


1063   } break;
1064

        case JVM_CONSTANT_UnresolvedClassInError:
    case JVM_CONSTANT_MethodHandleInError:
   case JVM_CONSTANT_MethodTypeInError:
           assert(0, "should have been eliminated by normalize_error_tag");
           // fall through

1065   // Invalid is used as the tag for the second constant pool entry
1066   // occupied by JVM_CONSTANT_Double or JVM_CONSTANT_Long. It should
1067   // not be seen by itself.
1068   case JVM_CONSTANT_Invalid: // fall through
1069
1070   default:
1071     ShouldNotReachHere();
1072     break;
1073   }

Thanks
- Ioi

On 10/09/2013 07:04 PM, Coleen Phillimore wrote:
>
> Thanks Dan!
> Coleen
>
> On 10/9/2013 6:39 PM, Daniel D. Daugherty wrote:
>> On 10/8/13 12:27 PM, Coleen Phillimore wrote:
>>> Summary: Add missing cases.
>>>
>>> I verified this with the test for 
>>> https://bugs.openjdk.java.net/browse/JDK-8022701 but don't want to 
>>> copy the test into with modifications the hotspot repository, still 
>>> working on refactoring the test for the JDK repository for after 
>>> this gets pushed.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8025185/
>>
>> src/share/vm/oops/constantPool.cpp
>>     No comments.
>>
>> Thumbs up.
>>
>> Dan
>>
>>
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8025185
>>>
>>> Thanks,
>>> Coleen
>>>
>>>
>>
>



More information about the serviceability-dev mailing list