On 03/04/2017 07:28, Christoph Engelbert wrote:
Hi Mark, hi others,
First of all, I understand the idea behind this change and I think it certainly
makes sense but from my impression the default is wrong, as Volker already
pointed out.
Over the last few days I (with the help of others) put together a document
(https://docs.google.com/document/d/19H1iGUnyI4Y40U5sNVAmH0uLxcpNfYSjPIW3s0Rv5Ss/edit?usp=sharing
<https://docs.google.com/document/d/19H1iGUnyI4Y40U5sNVAmH0uLxcpNfYSjPIW3s0Rv5Ss/edit?usp=sharing>)
to see wich tools are affected by this change.
A survey of the agents that support being loaded into a running VM is
useful but I think would be more useful if it were expanded to capture:
1. Whether the agent depends on instrumentation of classes in core
modules (java.base in particular).
2. Whether the agent is deployed as a library that load an agent into
the current VM.
The combination of #1 and #2 is the problem in the cross-hairs. There
isn't any desire to disrupt out of process tools that load
instrumentation agents into a target VM.
-Alan.
