Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2021-04-23 Thread Alan Snyder
On Apr 21, 2021, at 11:40 AM, Alan Bateman wrote: > > Sure, if you are using native code then you have the full power of JVM TI and > JNI available. Project Panama is exploring how to restrict access to native > code, I think too early to say how this might extend to JNI. I looked at some of

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2021-04-22 Thread Rafael Winterhalter
On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter wrote: >> To allow agents the definition of auxiliary classes, an API is needed to >> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or >> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2021-04-22 Thread Andrew Dinn
On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter wrote: >> To allow agents the definition of auxiliary classes, an API is needed to >> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or >> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2021-04-21 Thread Alan Bateman
On 20/04/2021 21:26, Rafael Winterhalter wrote: I have earlier proposed to offer a "jdk.test" module that offers the Instrumentation instance via a simple API similar to Byte Buddy's. The JVM would not load this module unless requested on the command line. Build tools like Maven's surefire or

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2021-04-21 Thread Rafael Winterhalter
Hi Ron, we certainly do come from different backgrounds and therefore perspectives, I find this exchange of perspective to be the main advantage of this open mailing list. I do believe that I have an understanding of your angle, I tried to give my feedback since before Java 9 introduced the

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2021-04-21 Thread Ron Pressler
I think you’re coming to this discussion with a very different perspective from us, which makes understanding what is or isn’t on the table unclear, and also steers the ideas in directions that are different from the one we’re going. Our goal is not to maintain some status quo until such time

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2021-04-20 Thread Rafael Winterhalter
On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter wrote: >> To allow agents the definition of auxiliary classes, an API is needed to >> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or >> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2021-04-20 Thread Alan Bateman
On 19/04/2021 22:20, Rafael Winterhalter wrote: : At the moment, it is required for root to switch to the user that owns the JVM process as the domain socket is only accessible to that user to avoid that users without access to the JVM can inject themselves into a JVM. I am not sure if

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2021-04-19 Thread Rafael Winterhalter
On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter wrote: >> To allow agents the definition of auxiliary classes, an API is needed to >> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or >> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2021-04-19 Thread Alan Bateman
On 19/04/2021 15:10, Peter Levart wrote: : I hear Rafael that dynamic attach is important to support monitoring and instrumenting large numbers of JVMs with no preparations (i.e. without issueing special command-line options to enable it). As I understand, current attach mechanism is designed

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2021-04-19 Thread Peter Levart
On Mon, 19 Apr 2021 09:34:56 GMT, Alan Bateman wrote: > an application or library can use the attach mechanism (directly or via the > attach API in a child VM) to load an agent and leak the Instrumentation > object. This is the genie that somehow needs to be put back in its bottle. > One

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2021-04-19 Thread Alan Bateman
On Mon, 19 Apr 2021 09:11:34 GMT, Peter Levart wrote: > I think it would be easy to limit the use of this Instrumentation method to > the agent code as agent classes are loaded by the bootstrap classloader. > Simply make the method implementation caller-sensitive and check the caller > is

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2021-04-19 Thread Peter Levart
On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter wrote: >> To allow agents the definition of auxiliary classes, an API is needed to >> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or >> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2021-04-19 Thread Peter Levart
On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter wrote: >> To allow agents the definition of auxiliary classes, an API is needed to >> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or >> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2021-04-19 Thread Rafael Winterhalter
On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter wrote: >> To allow agents the definition of auxiliary classes, an API is needed to >> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or >> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed