Hi Mandy and Alan,
I very much understand your points of view that the Java instrumentation
API should retain its original intended scope and that every problem should
be solved at its own time. I do however claim that the proposed API does
not even solve this problem of auxiliary classes for the
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
On 02/07/2018 09:41, 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
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
Hei Mandy,
yes, this sums it up, I think and I have worked with all use cases where
sun.misc.Unsafe::defineClass is more then sufficient. One major issue I
also have with the current API are the costs in refactoring existing
agents, especially since one would need to deliver a seperate agent for
Hi Rafael,
Thanks for the additional use cases of Unsafe::defineClass and looking
through many different agents to identify their migration path.
Summarize the requirements you collected (please correct/add):
1. need a means to define auxiliary classes in the same runtime package
of an
Hei Mandy,
after further investigation I have found several other use cases of
sun.misc.Unsafe::defineClass for which the proposal for JDK-8200559 would
not currently offer a solution. I will try to describe a generic case of
the problem I found:
Java agents sometimes need to communicate state
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
https://bugs.openjdk.java.net/browse/JDK-8201784
This is the correct JBS issue (Sorry I cut-n-paste the wrong link).
Mandy
On 4/18/18 3:46 PM, mandy chung wrote:
Hi Rafael,
I think it's best to separate the testing requirement from java agents
doing instrumentation that may run in
Hei Mandy,
Generally I agree with you that these two should be seperate but I think
that there is a very blurry border between the two. Java agents are
sometimes used to test something in a production environment and there is a
long history of agent development that relies on the easy and general
Hi Rafael,
I think it's best to separate the testing requirement from java agents
doing instrumentation that may run in production environment.
I have created a JBS issue to track the testing mode idea that would
require more discussion and investigation:
Hei Mandy,
Lookup::defineClass would always be an alternative but it would require me
to open the class first. If the instrumented type can read the module with
the callback but its module was not opened, this would not help me much,
unfortunately. Also, I could not resolve this lookup as the
Hi Rafael,
I see that mocking/proxying/testing framework should be looked at
separately since its requirements and approaches can be different than
tool agents.
On 4/17/18 5:06 AM, Rafael Winterhalter wrote:
Hei Mandy,
I have looked into several Java agents that I have worked on and for
Hei Mandy,
I have looked into several Java agents that I have worked on and for many
of them, this API does unfortunately not supply sufficient access. I would
therefore still prefer a method Instrumentation::defineClass.
The problem is that some agents need to define classes in other packages
On 16/04/2018 08:11, Rafael Winterhalter wrote:
:
I also think it is essential to being able to inject a class into a
non-opened package. Otherwise one could use a method handle. When
instrumenting classes one already has full privilege for all packages
as an agent can open modules. If one
Hi David,
>From my perspective as a heavy user of this API in Unsafe today:
>From my experience, the recursive dependency is not a common problem as
auxiliary types normally only reference the instrumented type. Beyond, this
problem is an issue for such explicit dynamic class loading, also when
On 4/16/18 2:13 PM, David Holmes wrote:
Hi Mandy,
How do you handle dependencies across a set of auxiliary types, i.e if
you are defining a new class A, and it depends on B (which you also
intend to define), how will the classloader resolve references from A
to B when it can't load B
Hi Mandy,
How do you handle dependencies across a set of auxiliary types, i.e if
you are defining a new class A, and it depends on B (which you also
intend to define), how will the classloader resolve references from A to
B when it can't load B itself?
Is the key capability here the ability
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
19 matches
Mail list logo
