[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: Review Request JDK-8200559: Java agents doing instrumentation need a means to define auxiliary c
From:       Alan Bateman <Alan.Bateman () oracle ! com>
Date:       2018-04-23 13:01:24
Message-ID: c3e78492-9fc1-ffff-74cb-63aa33f8ec79 () oracle ! com
[Download RAW message or body]

On 15/04/2018 07:23, mandy chung wrote:
>
>
> 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/
I went through the proposed spec/API addition and it looks good. The 
original instrumentation envisaged in JSR 163 was to support data 
collection by tools (profilers, tracing, etc.) and it's not unreasonable 
that such instrumentation would make use of (ideally non-public) helper 
classes that the agent defines into the same run-time package as the 
instrumented class.

The reentrancy issues with transform implementations loading or defining 
new classes is very tricky so I think the proposal to not send the 
auxillary classes through the transformer pipeline is pragmatic. It 
means a small inconsistent with JVM TI but I don't think this matters 
too much.

A minor suggestion is to replace "The transformers can ..."   with 
"Transformers may". The rest of the wording looks good.

-Alan


[prev in list] [next in list] [prev in thread] [next in thread]