RFR: 8200559: Java agents doing instrumentation need a means to define auxilary classes

Rafael Winterhalter winterhalter at openjdk.java.net
Fri Apr 16 20:09:34 UTC 2021

On Fri, 16 Apr 2021 13:44:16 GMT, Rafael Winterhalter <winterhalter at openjdk.org> 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 from `sun.misc.Unsafe`.

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-private types or methods which is really only relevant for the
Spring framework, but even there I do not think it's such a big area that
it cannot be addressed. Non-agent code generation is typically the use of
proxies where the code generation framework is sharing a class loader with
the user code and there is normally a way to weave it. Agents on the other
hand have to deal with unknown class loader hierarchies and it can be
necessary to inject code into a common class loader parent without
instrumenting classes in this loader or even knowing any classes of this
loader. It's really agents where this is required and therefore
Instrumentation is a good target for such an addition.

I have never heard about a 'discussion [that] will eventually lead into
putting at least some restrictions on agents loaded into a running VM' and
as a heavy user and someone who has helped to write a long row of
commercial agents and followed them into their use in production and who
has seen how helpful they are in reducing deployment complexity, I can only
hope that you will change your mind on this. Dynamically attached agents
must already run as the same user as the target process. If you are
concerned about agents 'illegally intruding' your Java process, I'd say you
have bigger security issues at hand and it is already possible to disable
dynamic attachment if you want to avoid it. Dynamic attachment has become
pretty much the default approach for a lot of Java tooling in production
environments. It has proven to be very convenient if a for example a
tracing tool is scanning Java processes to attach to them, rather than
requiring the deployment operators to be explicitly set up command line
arguments which are easily forgotten if they only need to be added in some
environments. This reduction in complexity for operations has literally
saved millions of dollars to Java users and Oracle customers. This makes
Java a popular choice, especially compared to languages such as Go where
this is naturally not possible. It's easy and there is no record of this
feature doing any harm. I would not see any good reason to restrict this by

That said, even if it was restricted in the 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:33 Uhr schrieb mlbridge[bot] <

> *Mailing list message from Alan Bateman ***@***.***> on
> core-libs-dev ***@***.***>:*
> On 16/04/2021 17:40, Rafael Winterhalter wrote:
> :
> I will try to make my case on the mailing list. I hoped this could get
> resolved within the release of Java 17 as this would make it possible to
> write agents without use of Unsafe API to support Java 17 and later. Since
> agents often are supplementary to a broad range of Java applications, the
> LTS release will likely be an important support boundary for years and
> years to come.
> "are supplementary to a board range of Java applications" is part of the
> concern with the proposal. If possible, it would be good if the write-up
> could separate the requirements for injection/instrumentation by
> frameworks at runtime from the requirements of tool agents. If the
> requirements cover testing time and mocking then it would useful to
> separate those too.
> Just to add to R?mi's comment: For frameworks/libraries, the
> Lookup.defineClass and defineHiddenClass APIs are to define classes in
> the same run-time package as the Lookup class. There isn't any API for
> libraries/frameworks to define class in a "new run-time package".
> There's a chunky project there. Part of it is the Lookup API itself,
> part of is that there isn't an exposed way to extend the set of packages
> in a named module. Mandy has done some exploration on this topic and may
> be able to say a bit more about this.
> On Java agents, then I think the discussion will eventually lead into
> putting at least some restrictions on agents loaded into a running VM.
> Agents started on the command line with -javaagent are all-powerful but
> maybe agents loaded into a target VM get a restricted Instrumentation
> object that cannot redefine modules or retransform classes in named
> modules. The narrower requirement for agents doing load time
> instrumentation to define auxiliary classes in the same package as the
> class being loaded fits with the intent of the original API and I don't
> think is controversial.
> -Alan
>> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/3546#issuecomment-821329136>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABCIA4CCOJR6LGGDX5YSHQTTJBYG3ANCNFSM43BSDEGQ>
> .


PR: https://git.openjdk.java.net/jdk/pull/3546

More information about the core-libs-dev mailing list