JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 270 contents

Right after last month's newsletter was published and sent out, the draft JEP was altered to only issue a deprecation warning instead of actually flipping the DisableAttachMechanism default; then it was finalized and published.

As soon as the adapted JEP was published, I presented the objections I've been hearing from the Observability community, which have been strongly against the JEP. It turns out however, that objections to a JEP are defended in a court where the JEP sponsors are simultaneously prosecutor, judge and jury. You can easily imagine the fairness and outcome. (Make up your own mind - the full discussions are available in the java-dev and serviceability-dev archives).

My primary point was that this is, unusually, a very controversial JEP; that there is a strong preference by the community that it should NOT proceed; and that consequently the sponsors should get wider feedback from more forums. Not only was that suggestion repeatedly blanked, but shockingly we were told that what the community thinks, is irrelevant (email last line). I'm used to the observability bubble where we are delighted to get community feedback, especially for what people think about upcoming changes, and we try to respond to that feedback. So to find that the maintainer bubble was actively disinterested in what the wider JVM community wants, was actually shocking to me. Generally the maintainers have done a great job over the years. They've maintained and enhanced Java and the JVM superbly. It's a shame they have this disappointing attitude. If this JEP is such a great idea, it should be simple to convince the community to support it, rather than just force it through.

My future newsletters will of course keep you informed on any relevant developments in this space. So now, let's get 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

A note from this newsletter's sponsor

News

Java performance tuning related news

• Automated Detection of Software Performance Antipatterns in Java-Based Applications
• JEP 451, emit a warning when an agent is loaded using the attach API (unless -XX:-DisableAttachMechanism is set). This will change in a future JVM version to actively disable such agent loading unless the flag is set. At which point the advice by pretty much everyone that supports actual production JVMs will be to include that flag as a default command option for every JVM
• JCStress 0.16 released

Tools

Java performance tuning related tools

• Hollow, toolset for disseminating in-memory datasets from a single producer to many consumers for high performance read-only access
• HPPC: High Performance Primitive Collections
• Externalsortinginjava External-Memory Sorting in Java: useful to sort very large files using multiple cores and an external-memory algorithm

Articles

• "Show Me the Garbage!", Garbage Collection a Friend or a Foe (Haim Yadid/NLJUG)
• A Glance At The Java Performance Toolbox (Ana-Maria Mih?lceanu/Voxxed Days Bucharest)
• Reduce network calls in a Java applications (Srikanth Dannarapu/Javarevisited)

Jack Shirazi

Back to newsletter 270 contents