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`
ty sooner rather than later. Our goal, then,
> should be to make people’s life
> easier, but only under these constraints, that, at this point, should be
> taken as an axiom for the purpose
> of discussion.
>
> — Ron
>
> > On 20 Apr 2021, at 21:26, 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`
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`
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`
hr schrieb Alan Bateman <
alan.bate...@oracle.com>:
> On 16/04/2021 21:09, Rafael Winterhalter wrote:
> > I have never seen a need for a non-agent to define a class in a
> > non-existing package. Injection is typically required if you want to work
> > with package-pr
> 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
> from `sun.misc.Unsafe`.
Rafael Winterhalter has r
future, this would mean that
some of the Instrumentation API methods will throw exceptions in the
future. There would not be much difference if an introduced defineClass
method would do the same.
Am Fr., 16. Apr. 2021 um 19:31 Uhr schrieb Alan Bateman <
alan.bate...@oracle.com>:
> On 16/04/2021 1
On Fri, 16 Apr 2021 13:44:16 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 wa
managerial toll on agent authors. I would hope that an API equally
convenient to today's unsafe options could be added.
Am Fr., 16. Apr. 2021 um 18:35 Uhr schrieb :
>
>
> --
>
> *De: *"Rafael Winterhalter"
> *À: *"Remi Forax"
&
On Fri, 16 Apr 2021 13:44:16 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 wa
nal -
> > De: "Rafael Winterhalter"
> > À: "core-libs-dev" ,
> "serviceability-dev"
> > Envoyé: Vendredi 16 Avril 2021 15:52:07
> > Objet: RFR: 8200559: Java agents doing instrumentation need a means to
> define auxilary classes
>
> &g
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 from
`sun.misc.Unsafe`.
-
Commit messages:
- 8200559: Jav
e 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.
>>
>&
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
util.AgentDispatcher).
> The proposed API requires more work than the existing
> Unsafe::defineClass that can define a class in any package but
> still plausible, right?
>
> We should explore other alternatives, if any.
>
> Mandy
> [1] http://mail.openjdk.java.net/pipermail/se
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 fr
n any
> package and you can achieve by calling retransformClasses.
>
> What do you think?
>
> Mandy
>
> On 4/18/18 5:23 AM, Rafael Winterhalter wrote:
>
> Hei Mandy,
> Lookup::defineClass would always be an alternative but it would require me
> to open the class first. If the i
ts.
>
> 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 many
> of them, this API does unfortunately not supply sufficient access. I would
> therefore still prefer a method Instrumentatio
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
th
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
u
21 matches
Mail list logo
