RFR: 8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops
Serguei Spitsyn
sspitsyn at openjdk.java.net
Tue Jun 14 07:16:59 UTC 2022
On Tue, 14 Jun 2022 07:01:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
>> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those fields are used, and therefore this is a serious bug. These ops seem to be used only from a few corner cases, which is probably why this was never actually found in testing.
>>
>> Additional testing:
>> - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom`
>> - [x] Linux x86_64 fastdebug, `serviceability/jvmti`
>
> Looks good.
> Thank you for catching and fixing it.
> -Serguei
> @sspitsyn @lmesnik If I read this correctly then this calling JVMTI GetFrameCount or GetStackTrace with a jthread to a virtual thread that is not mounted. I'm surprised this wasn't caught by any tests. Should we add tests for these cases?
I think we have good enough test coverage for these two JVMTI functions (will double-check tomorrow).
I hope that Leonid can confirm the same.
Probably, we do not see the existing tests failing because, the functions:
JvmtiEnvBase::get_stack_trace(javaVFrame *jvf,
jint start_depth, jint max_count,
jvmtiFrameInfo* frame_buffer, jint* count_ptr)
and
` JvmtiEnvBase::get_frame_count(javaVFrame *jvf)`
never use `this` parameter. So, they could be made static.
The same can be true for overloaded JavaThread based functions.
-------------
PR: https://git.openjdk.org/jdk19/pull/10
More information about the serviceability-dev
mailing list