Slow class loading when running JVM in debug mode

Volker Simonis volker.simonis at gmail.com
Thu Jun 20 20:31:58 UTC 2019


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> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190620/b41a3eae/attachment.html>


More information about the serviceability-dev mailing list