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