On Fri, 26 Aug 2022 20:13:28 GMT, Serguei Spitsyn <sspit...@openjdk.org> 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?
-------------
PR: https://git.openjdk.org/jdk/pull/10051
