On Wed, 4 Nov 2026 11:22:52 GMT, Markus Grönlund <[email protected]> wrote:
>> src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 154:
>>
>>> 152: // A thread attaching via JNI does not go through _thread_new
>>> state
>>> 153: JfrCPUTimeThreadSampling::on_javathread_create(jt);
>>> 154: }
>>
>> Alternative fix:
>>
>> if (jt->thread_state() == _thread_new) {
>> return;
>> }
>> assert(jt->thread_state() == _thread_in_vm, "invariant");
>> JfrCPUTimeThreadSampling::on_javathread_create(jt);
>
> Can the sampler issue a an interrupt while the thread is still in _thread_new?
>
> You are safe anyway, because the thread has already been assigned an id.
>
> But if you are not sampling _thread_new states, then the alternative fix
> makes sense.
In theory, it can: `JfrCPUTimeThreadSampling::on_javathread_create` arms CPU
timer, so that a thread may start receiving signals. However, for threads in
`_thread_new` state, the signal handler does nothing but incrementing the
`lost_samples` counter.
The only lengthy operation that happens in between is creating stack guard
pages. Whether to include it in cpu-time measurement or not, does not make much
difference in practice, imo.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/33678#discussion_r4467178818
