Tools for profiling, debugging, monitoring, thread analysis, and test coverage analysis can attach to the Java Virtual Machine (JVM) using the 'Tool Interface'

If you've got a running java process on your local machine right now, you can use 'jconsole' to see the stack traces of all threads, inspect various memory statistics, trigger an immediate garbage collection or heap dump, and so on. And of course, if the tool is an instrumenting profiler - it needs the power to modify the running code, to insert its instrumentation. Obviously you need certain permissions on the host to do this - just like attaching gdb to a running process.

This capability is used not just by for profiling, debugging and instrumentation but also by mockito to do its thing.

Java 21 introduced a warning [1] saying this will be disabled in a forthcoming version, unless the process is started with '-XX:+EnableDynamicAgentLoading' - whereas previously it was enabled by default and '-XX:+DisableAttachMechanism' was used to disable it.

The goal of doing this is "platform integrity" - preventing the attachment of debugging tools is useful in applications like DRM.

[1] https://openjdk.org/jeps/451

See https://openjdk.org/jeps/451: JEP 451: Prepare to Disallow the Dynamic Loading of Agents, which has a lot of background on the topic.

A JVM agent is able to instrument and modify running JVM applications. Stuff like debugging, hot patching, etc rely on this. You used to be able to tell the JVM to listen on a port where you could connect debuggers (agents) dynamically at runtime, but that was deemed a security issue so now you can only declare specific agents at launch time through command-line flags.