Debugger overhead for virtual threads creation

[Egor Ushakov]

Thanks Chris!

I've made the bug https://youtrack.jetbrains.com/issue/IDEA-365900 
visible, there's a reproducer there.

Thanks,
Egor

On 02.04.2025 01:39, Chris Plummer wrote:
> The short answer is yes. The debug agent needs to deal with 
> JVMTI_EVENT_VIRTUAL_THREAD_START/END events for every virtual thread. 
> What makes it worse is when there are a large number of virtual 
> threads that are currently alive. They are tracked on a list of 
> ThreadNodes that starts to slow down debug agent performance when it 
> gets too long. I have a work in progress that proactively purges these 
> ThreadNodes so the list does not get too big. I've been meaning to 
> revive this project for quite some time. If you have a test case I'd 
> be willing to experiment with these changes some more. I could not 
> access to the IDEA-365900 link you provided.
>
> Note I think after the work is done to purge ThreadNodes proactively 
> it might not be that hard of step to move to not needing 
> JVMTI_EVENT_VIRTUAL_THREAD_START/END events enabled, which will help 
> performance a lot more.
>
> Chris
>
> On 4/1/25 10:14 AM, Egor Ushakov wrote:
>> Hi everyone!
>>
>> Is it expected that with the debugger attached creating virtual 
>> threads is much slower?
>> We're getting bugs like: 
>> https://youtrack.jetbrains.com/issue/IDEA-365900
>> And I can reproduce it easily with jdb...
>> Just attaching the debugger immediately slows down virtual threads 
>> creation significantly.
>>
>> >java 
>> -agentlib:jdwp=transport=dt_shmem,server=y,suspend=n,address=8000 app
>> ...
>> 6808805 (1.2046688E7 threads per second)
>> ...
>> after >jdb -attach 8000
>> ...
>> 30215 (95986.055 threads per second)
>> ...
>>
>> Thanks,
>> Egor