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