Java agents doing instrumentation need a means to define auxiliary classes

Tool agents that instrument code with references to agent provided classes need to ensure that those classes are visible to the and accessible to the instrumented class. Instrumentation's appendToBootstrapClassLoaderSearch​ and appendToSystemClassLoaderSearch​ APIs are too limited - they aren't useful when the bytecode of the supporting classes is generated with the intention of being loaded into the same runtime package as the instrumented class (a non-public helper class for example).

This issue was brought up here:
   http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000405.html

This issue tracks updating the java.lang.instrument API to allow agents doing load time or dynamic instrumentation to define additional classes in the same runtime package as the class being transformed. There are several approaches and API choices to examine.