2017/4/4 3:45:02 -0700, Andrew Dinn <ad...@redhat.com>: > Thanks again for another thoughtful and well-reasoned response.
Thank you for the continued dialogue. > On 03/04/17 23:36, mark.reinh...@oracle.com wrote: >> 2017/4/3 9:44:43 -0700, Andrew Dinn <ad...@redhat.com>: >>> ... >>> >>> I'm very happy to consider all sorts of half-way houses or even -- in >>> time -- the full change recommended in the original JIRA. For example, >>> rejecting instrumentation in some specific set of bootstrap/JDK module >>> classes (like, say, java.base) from an agent which has been dynamically >>> loaded might well be a workable compromise -- that at least allows users >>> to employ an agent to tweak any code that is in the classpath through >>> their choice. >> >> That's an interesting option, and worth exploring further. It could, >> though, be troublesome for legitimate late-binding agents that instrument >> JDK internals. Is Byteman typically used in that way? > > Well, if it helps to provide the guarantees that the JDK runtime or core > runtime wants in order to enable performance improvements then I'd > certainly be /interested/ in a restriction that merely put certain > classes out of reach of dynamic agents (assuming it also comes with an > option to remove that restriction). > > Of course,-- to answer your question -- that would still present a > problem for Byteman; it is often used to inject into core (java.base) > classes. > > There are quite a few unit/integration testing scenarios where the > ability to tweak the operation of core JDK runtime code is really > useful. For example, injecting a THROW rule into class File to simulate > an IOException is probably the poster-child for Byteman fault injection. > > The same also applies when using Byteman for runtime diagnosis. A very > good example of that was when one of our customers kept finding that the > first connection obtained from a connection pool would always fail with > a connection error. Trace code injected into Thread.isInterrupted > revealed the reason for the failure -- the application thread's > interrupt state was already set before the open attempt. A stack > backtrace call injected into Thread.setInterrupted showed that a 3rd > party library was invalidly setting (and then not clearing) the > interrupted state as part of application thread initialization. Very interesting use cases! > So, in summary: > > I'm interested in the option for a default setting to provide limited > access to runtime and/or application classes from dynamically loaded > agents -- it's an improvement on no access at all. Got it. > However, on Byteman's account, I'd still really prefer the ability to > support full access in the JDK9 time frame with a move to whatever more > limited access is determined appropriate in JDK10 (for the reasons > already mentioned). Okay, I think I'm starting to see how to revise the proposal. I'll try to write something up and post it tomorrow. - Mark
