Click the Start a free trial link to start a 15-day SaaS trial of our product and join our community as a trial user. If you are an existing customer do not start a free trial.
AppDynamics customers and established members should click the sign in button to authenticate.
A JVM crash is always a result of a JVM bug (unless it is triggered by an issue in native code accessed through JNI. The AppDynamics agent contains no native code) . Of course, adding an agent to the JVM changes what is going on within the JVM (for instance, classes getting retransformed would not happen with no agent present) which can cause JVM bugs to be triggered which are not triggered in the absence of the agent.
Unfortunately, selecting g1gc seems to uncover more bugs of this nature than you might hope (often, coincident with class retransformations)
You need to see if the crash backtrace corresponds to a known JVM bug and if so, upgrade to a JVM where it is fixed. Or select a different GC algorithm. Or, you can disable dynamic class retransformations which does seem to avoid many of these issues (at the expense of not being able to change instrumentation on the fly)
What does this options means?
Does it disable able agent on-the-fly configuration changes (ie, if we change BT definition, we will require application restart)?
If the JVM crash is caused by retransformation, which trigger the JVM bug.
Does AD agent reveal on log messages about the retransformation behavior?