RFR (XS): 8223718: Checks in check_slot_type_no_lvt() should be always executed

[serguei.spitsyn at oracle.com]

Thanks a lot, Gary and Alex for reviewing!
Serguei


On 5/30/19 09:52, Gary Adams wrote:
> +1
>
> On 5/30/19, 12:39 PM, Alex Menkov wrote:
>> Looks good.
>>
>> --alex
>>
>> On 05/29/2019 19:32, serguei.spitsyn at oracle.com wrote:
>>> Thanks, Gary!
>>> I've fixed the copyright year in the test and split the updated lines.
>>> Also found some inconsistent use of cached local variables and fixed 
>>> it.
>>>
>>> The webrev location is the same:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ 
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 5/29/19 7:04 PM, gary.adams at oracle.com wrote:
>>>> Be sure to check copyright dates and line lengths.
>>>>
>>>> On 5/29/19 6:24 PM, serguei.spitsyn at oracle.com wrote:
>>>>> Please, review fix for:
>>>>>   https://bugs.openjdk.java.net/browse/JDK-8223718
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ 
>>>>>
>>>>>
>>>>>
>>>>> Summary:
>>>>>   The JVMTI GetLocal<TYPE>() does not return the error code
>>>>>   JVMTI_ERROR_INVALID_SLOT for the T_CONFLICT if the LVT is present.
>>>>>   The fix is to always execute the check_slot_type_no_lvt().
>>>>>   The test nsk/jvmti/unit/GetLocalVariable/getlocal003 is updated
>>>>>   to expect the error code JVMTI_ERROR_INVALID_SLOT additionally to
>>>>>   the JVMTI_ERROR_TYPE_MISMATCH in a couple of cases.
>>>>>
>>>>> Testing:
>>>>>   Successful execution of the nsk.jvmti tests (release/fastdebug).
>>>>>   Mach5 run is in progress.
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>>
>>>>
>>>
>