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
-----------
