Review Request JDK-8200559: Java agents doing instrumentation need a means to define auxiliary classes

[mandy chung]

My proposal of ClassDefiner API allows the java agent to define 
auxiliary classes in the same runtime package of the class being 
instrumented.  You raised other use cases that are not addressed by this 
proposal.  As Alan replied, the ability to define any arbitrary class 
would be an attractive nuisance and we think Instrumentation.defineClass 
isn't the right API to add.

I think the proposed ClassDefiner API is useful for the specific use 
case (define auxiliary classes in the runtime package of the class being 
instrumented).  I hold it off and so didn't make 11.  For the other use 
cases, perhaps we should create JBS issues for further investigation.

Mandy

On 7/2/18 1:41 AM, Rafael Winterhalter wrote:
> Hi,
> 
> I was wondering if a solution for this problem is still planned for JDK 
> 11 giving the beginning ramp down.
> 
> With removing sun.misc.Unsafe::defineClass, Java agents only have an 
> option to use jdk.internal.misc.Unsafe::defineClass for the use-cases 
> that I described.
> 
> I think it would be a missed opportunity not to offer an alternative as 
> of JDK 11 as a second migration would make it even less likely that 
> agents would avoid unsafe API.
> 
> Thanks for the information,
> best regards, Rafael
> 
> mandy chung <mandy.chung at oracle.com <mailto:mandy.chung at oracle.com>> 
> schrieb am So., 15. Apr. 2018, 08:23:
> 
>     Background:
> 
>     Java agents support both load time and dynamic instrumentation. At
>     load time,
>     the agent's ClassFileTransformer is invoked to transform class
>     bytes.  There is
>     no Class objects at this time.  Dynamic instrumentation is when
>     redefineClasses
>     or retransformClasses is used to redefine an existing loaded class.  The
>     ClassFileTransformer is invoked with class bytes where the Class
>     object is present.
> 
>     Java agent doing instrumentation needs a means to define auxiliary
>     classes
>     that are visible and accessible to the instrumented class. Existing
>     agents
>     have been using sun.misc.Unsafe::defineClass to define aux classes
>     directly
>     or accessing protected ClassLoader::defineClass method with
>     setAccessible to
>     suppress the language access check (see [1] where this issue was
>     brought up).
> 
>     Instrumentation::appendToBootstrapClassLoaderSearch and
>     appendToSystemClassLoaderSearch
>     APIs are existing means to supply additional classes.  It's too limited
>     for example it can't inject a class in the same runtime package as
>     the class
>     being transformed.
> 
>     Proposal:
> 
>     This proposes to add a new ClassFileTransformer.transform method
>     taking additional ClassDefiner parameter.  A transformer can define
>     additional
>     classes during the transformation process, i.e.
>     when ClassFileTransformer::transform is invoked. Some details:
> 
>     1. ClassDefiner::defineClass defines a class in the same runtime package
>         as the class being transformed.
>     2. The class is defined in the same thread as the transformers are being
>         invoked.   ClassDefiner::defineClass returns Class object directly
>         before the transformed class is defined.
>     3. No transformation is applied to classes defined by
>     ClassDefiner::defineClass.
> 
>     The first prototype we did is to collect the auxiliary classes and
>     define
>     them  until all transformers are invoked and have these aux classes
>     to go
>     through the transformation pipeline.  Several complicated issues would
>     need to be resolved for example timing whether the auxiliary classes
>     should
>     be defined before the transformed class (otherwise a potential race
>     where
>     some other thread references the transformed class and cause the code to
>     execute that in turn reference the auxiliary classes.  The current
>     implementation has a native reentrancy check that ensure one class
>     is being
>     transformed to avoid potential circularity issues.  This may need
>     JVM TI
>     support to be reliable.
> 
>     This proposal would allow java agents to migrate from internal API
>     and ClassDefiner to be enhanced in the future.
> 
>     Webrev:
>     http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8200559/webrev.00/
> 
>     Mandy
>     [1]
>     http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000405.html
>