On Wed, 4 Nov 2026 13:44:16 GMT, Markus Grönlund <[email protected]> wrote:
>> 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.
>
> Could be folded into:
>
>
> JavaThread* const jt = JavaThread::cast(t);
> if (jt->thread_state() == _thread_in_vm) {
> JfrCPUTimeThreadSampling::on_javathread_create(jt);
> if (tl->should_write()) {
> JfrCheckpointManager::write_checkpoint(t);
> }
> send_java_thread_start_event(jt);
> if (tl->has_cached_stack_trace()) {
> tl->clear_cached_stack_trace();
> }
> return;
> }
Yes, I like the folded version.
The problem is, it introduces another scenario of
https://bugs.openjdk.org/browse/JDK-8396148, where
`JfrCPUTimeThreadSampling::on_javathread_create` can be called twice for the
main thread: one during `-XX:StartFlightRecording` enrollment, another from
`JNI_CreateJavaVM_inner`.
I have another PR that fixes this issue:
https://github.com/openjdk/jdk/pull/33651
Once that PR is integrated, I'm happy to make the discussed change.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/33678#discussion_r4469505535
