|
|
|
|
Back to newsletter 269 contents
A draft JEP has been published which, if implemented, will stop a large swathe of troubleshooting and monitoring tools from working on JVMs (without having to first restart them with an option change). The draft JEP asserts with no evidence that "most serviceability tools do not rely on dynamically loaded agents" which seems to ignore the many many projects in github that use remote agent loading.
The odd thing about this draft JEP is that it seems to be ideological only. There appears to be almost no benefit to it, but substantial downside. There would be no beneficial changes to the core JVM code from adopting it, no additional features enabled or planned to be enabled. (There would be a tiny amount of additional security, but remote agent loading is already limited by OS privileges so you must already have full access to the running JVM process and memory before you can attach).
For the tiny minority of systems that want to enforce no remote agent loading, you can already do so in any JVM9+ with the -XX:-EnableDynamicLoading option. You can even disable the attach mechanism entirely with -XX:+DisableAttachMechanism.
Every change to the JVM has benefits and disadvantages - the concrete benefits need to outweigh the disadvantages for the change to proceed, and I can't even see concrete benefits here. I can only hope ideology doesn't triumph over pragmatism and usefulness. JVM serviceability is one of the huge advantages it has over other runtimes, and reducing that capability for no benefit makes no sense to me. Now on to all the usual newsletter list of links, tips, tools, news and articles, and as usual I've extracted all the tips into this month's tips page
Java performance tuning related news
Java performance tuning related tools
Back to newsletter 269 contents
