Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

Alan Bateman Alan.Bateman at
Thu Sep 29 19:06:12 UTC 2016

On 29/09/2016 18:50, Rafael Winterhalter wrote:

> :
> Therefore I want to propose adding a static method to the Instrumentation
> interface:
> interface Instrumentation {
>    static Instrumentation getInstance(boolean redefine, boolean retransform,
> boolean nativePrefix) {
>      // security manager check
>      return getInstance0(redefine, retransform, nativePrefix);
>    }
> }
The original intention, back in JSR 163, was that java.lang.instrument 
be for instrumentation agents, not applications. This is why the API 
deliberately does not include a method to get the Instrumentation object 
along the lines you have propose. Sure, you can leak it from an agent 
started on the command line or attached at runtime but that is not the 
original intention. So I think introducing this method is a very 
significant change that would require a lot of consideration (previous 
requests to provide a way for applications to get the Instrumentation 
object without an agent in the picture were resisted).

Separately, introducing this method creates a complication for runtimes 
that do not have JVM TI support (the JPLIS agent is based on JVM TI). As 
things stand then it's possible to create a runtime that does not have a 
means to start agents from the command-line (the spec allows this) and 
so there is no need to have the implementation support for this API. So 
if a method like this is every introduced then it would either have to 
be optional or it would require changes to the JVM TI spec to make it 
non-optional (or is based on an alternative JPLIS implementation that 
doesn't use JVM TI).


More information about the core-libs-dev mailing list