2017/4/6 3:09:49 -0700, Andrew Dinn <ad...@redhat.com>: > On 05/04/17 17:15, mark.reinh...@oracle.com wrote: >> Thanks to everyone for the quick feedback on this topic, and especially >> to Andrew for the constructive dialogue. >> >> Here's a revised proposal: >> >> - Define a new VM option, `-XX:+EnableDynamicAgentLoading`, that's >> on by default in JDK 9 but off by default in JDK 10. >> >> This will allow launch scripts that use this option on JDK 10 to >> work on JDK 9 without change, and will allow early testing of the >> JDK 10 behavior on JDK 9. > > This at the least is very welcome. It will give Red Hat and others the > time needed to prepare their users for for this change. > >> - Revise the `com.sun.tools.attach` API to forbid attachment to the >> current process or to an ancestor of the current process, and >> define a read-only system property that allows such attachment to >> be enabled via the command line. >> >> This will discourage the inadvertent use of libraries that, for >> better or for worse, intentionally violate strong encapsulation. > > I guess I'm agnostic to this. I'm certainly not against it. > > Is this change being proposed for JDK9 or JDK10?
JDK 9. With `-XX:+EnableDynamicAgentLoading` off by default in JDK 9, this is one of the few ways we have left to discourage the use of encapsulation-busting libraries. >> ... >> >> Taken together, these changes are intended to enable the continued use >> of legitimate dynamically-loaded agents without change on JDK 9 and with >> a small change on JDK 10. That later change will align the treatment of >> such agents with the other means of breaking encapsulation (`--add-opens`, >> etc.) in order to ensure integrity by default for all code. > > That's a compromise position I can live with. Much as I want to retain > the ability to load my agent dynamically I also acknowledge that this is > one side of a trade-off. In particular, this proposal incorporates the > need for the JVM /eventually/ to have -- as a default -- a guarantee > that some portion of the code base cannot be subject to change and hence > is available for optimization without the need for ever more complex > apparatus to ensure later de-optimization. That's something I understand > the significance of and regard as very important for the future of the > JVM and JVM-based languages (not just Java). Indeed! That's a good summary of the tradeoff. > ... > >> This proposal does not attempt to lock down platform classes as distinct >> from user classes. Many agents have legitimate reasons to transform >> platform classes, so an additional mechanism to protect those classes >> does not appear to be worthwhile. > > I'm happy with this although it might be worth reviewing it later. Yes -- it wouldn't surprise me if we come back to this as we start to leverage integrity invariants for optimization. - Mark
