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:
|
- Slow class loading when running JVM in debug mode Egor Ushakov
- Re: Slow class loading when running JVM in debug mode Volker Simonis
- Re: Slow class loading when running JVM in debug m... Chris Plummer
- Re: Slow class loading when running JVM in deb... Egor Ushakov
- Re: Slow class loading when running JVM in... Chris Plummer
- Re: Slow class loading when running J... Egor Ushakov