Yes, I looked on it and tested when Tom proposed changes.
Vladimir
On 5/30/19 10:58 AM, [email protected] wrote:
Hi Vladimir,
May I count you as a (R)eviewer?
Thanks,
Serguei
On 5/30/19 10:05, Vladimir Kozlov wrote:
Thank you, Serguei, for fixing this.
Vladimir K
On 5/29/19 7:32 PM, [email protected] 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, [email protected] wrote:
Be sure to check copyright dates and line lengths.
On 5/29/19 6:24 PM, [email protected] 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
