Slow class loading when running JVM in debug mode

[Egor Ushakov]

I filed https://bugs.openjdk.java.net/browse/JDK-8227269.
Not sure that we could fix that ourselves.

Egor

On 21-Jun-19 21:50, Chris Plummer wrote:
> You might also want to have a look at:
>
> JDK:8214892: Delayed starting of debugging via jcmd
>
> This should allow you to defer initialization of the debug agent (and 
> the creation of the loaded classes cache) until you turn on debugging 
> using the jcmd (and the presumably follow that with an attach from a 
> debugger).
>
> Note there is also an after-the-fact CSR in progress for this which 
> might result in an eventual name change for debug agent option and 
> jcmd command.
>
> Chris
>
>
> On 6/21/19 3:06 AM, Egor Ushakov wrote:
>> 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
>
>

-- 
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/20190704/7bbf1650/attachment.html>