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

[Andrew Dinn]

Sorry, let me correct some of my mangled grammar

On 27/03/2023 17:06, Andrew Dinn wrote:
> 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 is a 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 removes opportunities 
> for the runtime to operate more 
> efficiently and, as a result, causes 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
> -----------
> 

-- 
regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill