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