[External] : Re: Disallowing the dynamic loading of agents by default

[Andrew Dinn]

On 27/03/2023 13:37, Volker Simonis wrote:
>> The JEP itself is rather ambitious because I noticed that most of the strong encapsulation JEPs lacked a substantial motivation section (largely because they had been written before that became the norm) and so strong encapsulation has not been motivated in JEP form, and this is an opportunity to start rectifying that. This is important because some, even in this discussion, are under the impression that integrity is about security. Although security is certainly one of integrity’s impacts (albeit not in the way hypothesised in this discussion) other major impacts are on performance (including, though certainly not limited to, link-time optimisations that are of interest to Project Leyden) and code evolution (the lack of integrity has been, by far, the biggest cause of JDK upgrade issues experienced by many applications an libraries).
> 
> Thanks for pointing out that "integritiy" and "security" are two
> different things and that this discussion is mostly about other
> aspects of "integrity" like performance and code evaluation. This is
> actually exactly why I already tried to ask several times about the
> "real" and/or the long term background of this change. Currently the
> JEP only seems to propose the change of the default value for dynamic
> agent loading. It is obviously not hard for other JDK vendors to use a
> different default and I agree that it is probably still manageable
> (though inconvenient) for administrators/operators to change the
> default at launch time. BUT, you rightly mention that once higher
> integrity is the DEFAULT, this opens the door for future optimizations
> (you listed some of them) and even completely different execution
> models / semantics for Java applications (e.g. as explored by Project
> Leyden). Once such new optimizations will be in place (and only work
> for the default, disabled dynamic agent loading setting) it will be
> much harder for users who depend on dynamic loading to enable it,
> because it will either impact their performance or it will limit their
> ability to use certain platform features.

Red Hat's team had discusssed this issue and we did think about raising 
it in the previous reply. It is perhaps better left for the JEP 
discussion but we certainly consider it as important an issue as Volker 
does.

Personally, I will note that this has been point I have been concerned 
by since the associated dilemma was raised by Mark Reinhold during the 
original discussion. Indeed, the possibility that retaining agents might 
necessitate a divergence in JVM (or even JDK) behaviour from the status 
quo when no agent is, nor can be, installed struck me very hard. My 
take-away was not an immediate abreaction. Rather: the opportunity 
agents provide for dynamic adaptation of the runtime is provisional and, 
needs to be balanced against the benefits that might accrue from them 
not being the picture; in the longer term some of the capabilities 
provided through the use of agents may be unsustainable.

As an example of that I considered my agent, Byteman. It is immensely 
useful for injecting faults, validity assertions and monitoring 
capabilities into app code during unit system testing, avoiding the need 
for that code to actually appear in the product. The precise targeting 
of Byteman rules to specific code locations means that the injected code 
only minimally perturbs the whole code base.

Notably, Byteman does not support bulk (online) transformation. Too much 
transformed code means you are effectively testing a very different app 
to the one you deploy, at least as far as execution speed, timings, 
resource use etc are concerned, and possibly even because of too radical 
a change to the app semantics.

Clearly, if simply loading an agent provides opportunities may 
eventually lead to for the runtime being able to operate more 
efficiently and, as a result, cause in a significant change in execution 
speed, timings, resource use then a tool like Byteman becomes much less 
useful for this sort of testing. So, for me the writing was already on 
the wall back in jdk9 time. We may well have to trade off of some 
build/test time benefits against the undeniable impetus to improve 
deploy-time performance.

> My main concern with the proposed change is not the current proposal
> but the impact it will have on the evolution of Java. Java's dynamic
> features are one of its biggest strength and a major reason for its
> success. Sacrificing some of them or making their usage increasingly
> expensive requires a broader discussion in the community and shouldn't
> happen "under the hood". I'm happy to continue that discussion on the
> actual JEP proposal.
Amen to that.

regards,


Andrew Dinn
-----------