On Fri, 26 Aug 2022 20:42:01 GMT, Chris Plummer <[email protected]> wrote:
>> If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the
>> thread parameter set to NULL (meaning current thread) then it should get/set
>> the value of the locals in the virtual thread frames. Instead, it reads the
>> carrier thread locals and/or crashes.
>>
>> The fix is that the relevant checking of the jthread parameter for NULL and
>> adjusting it to current thread is added.
>> It is done in new utility `function
>> current_thread_obj_or_resolve_external_guard(jthread thread)`. For more
>> convenient testing the same adjustment is done in the JVM TI extension
>> function `GetCarrierThread()`.
>>
>> The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add
>> previously missed test coverage.
>>
>> The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt
>> to update behavior of the `GetCarrierThread`.
>>
>> The fix was verified with the
>> test/hotspot/jtreg/serviceability/jvmti/vthread/ tests.
>>
>> The fix was also tested with the existing JVM TI and JDI tests to make sure
>> no regressions are introduced.
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/GetSetLocalTest/libGetSetLocalTest.cpp
> line 316:
>
>> 314: Values values1 = { NULL, NULL, 2, 3L, (jfloat)4.2F,
>> (jdouble)5.500000047683716 };
>> 315: // jthread cthread = at_event ? get_carrier_thread(jvmti, jni,
>> get_current_thread(jvmti, jni))
>> 316: // : get_carrier_thread(jvmti, jni,
>> vthread);
>
> Is there a reason to keep this around?
You are right. Will remove this.
-------------
PR: https://git.openjdk.org/jdk/pull/10051
