Comments inlined Chris
> On 5. Apr 2017, at 07:19, John Rose <john.r.r...@oracle.com> wrote: > > On Apr 3, 2017, at 3:36 PM, mark.reinh...@oracle.com wrote: >> >> If developers and deployers have to to opt-in to breaking encapsulation >> on the command line then that at least makes it clear to someone trying >> to diagnose a failing system that something fishy might be going on. > > It seems to me that some of the legitimate use cases use injected > code to perform similar diagnoses. Having been many times on the > wrong side of a failing system, I am sympathetic with any diagnostic > tool, no matter how invasive. And, yes, I give extra credit to tools > that can be applied online with no prearrangement. Not the only tools, as we have this “uber-jar” use case but I think that might have a better solution than the more general one we’re looking for to support those diagnostic tools :) > > This seems to lead back to allowing ad hoc code injection out > of the box. Would it help if, although there was not an opt-in > on the command line, there was some restriction about the > nature of the injected code? I'm thinking what we did with > JVMCI: Opened up a deep hole into the JVM, and then > protected it by sealing it into a module. Can we get the > module system to help us out here also? Maybe, out of > the box, your code must be inside some particular module > in order to do monkey-patching. Is there a way to do post > facto loading, during an emergency, into the privileged > module, of diagnostic code? (Probably not; modules are > static.) I already proposed, more as a side note, something like the Ubuntu / Debian alike repository private-public key signatures. If I want to have “privileged” modules (for example agents being attached at runtime) I have to trust the signature key. Anyhow I’m not looking for a certification process from Oracle side but a user can trust / mistrust key-pairs on their own by something like “jtrust add https://repository.company.com/key.asc <https://repository.company.com/key.asc>” which would be easy to explain to customers, adds a general “trust process” to all modules (for example to be reused in SecurityManager) and maybe other use cases. Still just a fix idea but maybe something to look into in the long term. > > Anyway, I imagine there are ways for instrumentation code > to be loaded that are far more controlled and explicit than the > current state of affairs, and still won't require prearrangement. > > Possibly all such ways will end up being too abusable. > But surely it is better to have a library that says "Hey, > I'm using/defining the monkey patching module", than > a random JAR that sneaks in and fires up a self-attach. It could be solved with layers (or different class loaders) and only modules on the same layer as the main JAR are ok to directly attach (in this specific use case)? > > A couple of other thoughts: > > 1. The "execute from JAR" use case seems to want a hook > for command line options. It's very ugly, but maybe that would > relieve pressure on users who cannot access command lines. > (But I'd much rather see problems solved by injecting a module > info file into a JAR, rather than some new command-line knobs.) > > 2. I think it is inevitable that we will be using the static structure > of modules, in future releases, to guide global optimizations. > Some of the hot-patching techniques people rely on today > will come into conflict with those optimizations. The JVM is > amazing at dealing with dynamically changing configurations, > but we also need to keep the option for static optimizations open, > in the long term. Sometimes the cost of switching from optimized > code to debug-mode must be so great that it won't be a viable > option, especially for online problem solving. > > HTH > — John > >
