Slow class loading when running JVM in debug mode

[Egor Ushakov]

Will have a look, thanks for advices!

On 21-Jun-19 00:42, Chris Plummer wrote:
> With respect to the specific issue brought up in 
> https://youtrack.jetbrains.com/issue/JBR-1611:
>
> "If we look into the code, we'll see that whenever a new class is 
> loaded and an event about it is delivered, when a garbage collection 
> has occurred, classTrack_processUnloads iterates over all loaded 
> classes to see if any of them have been unloaded. This leads to 
> O(classCount * gcCount) performance, which in case of frequent GCs 
> (and they are frequent, especially the minor ones) is close to 
> O(classCount^2). In IDEA, we have quite a lot of classes, especially 
> counting all lambdas, so this results in quite significant overhead."
>
> The debug agent calls JVMTI GetLoadedClasses() during initialization 
> to get a cache of all prepared classes. It keeps that cache up-to-date 
> by getting JVMTI CLASS_PREPARE events. When there is a gc, the debug 
> agent basically throws away the cache and creates a new one by calling 
> GetLoadedClasses() again. It also compares the old and new caches to 
> determine which classes where unloaded, and generates JDWP 
> CLASS_UNLOAD events for them (if there is a debugger attached that 
> wants them).
>
> It might be possible to defer initialization of the loaded classes 
> cache (and any maintenance of it) until there is a debugger attached. 
> I'm not sure if the only reason for the cache is for delivery of 
> CLASS_UNLOAD events, but at first glance that appears to be the case.
>
> Chris
>
> On 6/20/19 1:31 PM, Volker Simonis wrote:
>> Hi Egor,
>>
>> yes, I‘d say this is something well known. The reason for this is 
>> that a debugging agent will request some JVMTI capabilities like 
>> "can_access_local_variables" which can only be requested at JVM 
>> startup. However, once these capabilities have been taken, certain 
>> kinds of optimizations like for example Escape Analysis, can’t be 
>> done anymore which results in a performance degradation even if you 
>> don’t ever attach a debugger.
>>
>> We‘ve always enabled debugging in our commercial SAP JVM and called 
>> it „Debugging on Demand“ but usually didn’t observed any performance 
>> slowdown of more than 3-5% at most. We’ve started contributing some 
>> of the improvements we’ve done to make this possible to the OpenJDK.
>>
>> I’ve not looked into your concrete class loading use case. Maybe it’s 
>> possible to improve that. First you have to check by which JVMTI 
>> capability it is triggered and if that capability is really necessary 
>> for debugging and can only be requested at startup. If the answer is 
>> yes, you can still check if it’s not possible to improve the 
>> implementation of that capability in order to get a better runtime 
>> behavior.
>>
>> Regards,
>> Volker
>>
>>
>> Egor Ushakov <egor.ushakov at jetbrains.com 
>> <mailto:egor.ushakov at jetbrains.com>> schrieb am Do. 20. Juni 2019 um 
>> 11:36:
>>
>>     Hi everyone!
>>
>>     we have detected that a process started with the debug agent
>>     (even when
>>     debugger is not actually attached) may run significantly slower than
>>     without the agent, see:
>>     https://youtrack.jetbrains.com/issue/JBR-1611
>>     We all thought that without the debugger attached there should
>>     not be a
>>     difference.
>>     Is that something well known? Should we file a bug?
>>
>>     Thanks,
>>     Egor
>>
>>     -- 
>>     Egor Ushakov
>>     Software Developer
>>     JetBrains
>>     http://www.jetbrains.com
>>     The Drive to Develop
>>
>

-- 
Egor Ushakov
Software Developer
JetBrains
http://www.jetbrains.com
The Drive to Develop

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190621/dfaaef89/attachment-0001.html>