RFR (XS): 8223718: Checks in check_slot_type_no_lvt() should be always executed
Gary Adams
gary.adams at oracle.com
Thu May 30 16:52:33 UTC 2019
+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
>>>>
>>>>
>>>
>>
More information about the serviceability-dev
mailing list