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 268 contents

Each generation of programming language (GL) made us more productive. 4GLs (4th GLs) promised much but never delivered because they always ended up being ridiculously complex on the 10% of code that you need for optimizing performance, scaling up and handling reliability - which it turned out every project that was actually successful needed.

Instead of 4GLs, all the top languages today are 3GLs. This is a little odd. Our industry accelerated through machine code (1GL) and assembly (2GL) to 3GLs relatively quickly. Assembly was around in 1950 and by 1960 we already had several 3GLs. In the succeeding 60 years we've had multiple attempts at 4GLs, each time going nowhere or very niche. Yet 3GLs have been evolving the whole time. The top 3 languages - Java as the static typed winner, Python as the dynamic typed one and Javascript on the UI side - are all 25-30 years old. Older 3GLs lose market share and newer ones slowly gain some; this should be happening for 4GLs too, but isn't - at least not noticeably.

Instead what has happened is that IDEs have made us much more productive with 3GLs. Basically, current actual 4GLs are 3GL+IDE. They include not just code completion, generation and boiler plate filling features, but also performance and memory analysis tools. It's not a coincidence that the most popular heap analyzer - Eclipse MAT - is built atop an IDE, IDEs are a good base for tool building because of their productivity capabilities. And increasingly now, IDEs are adding some level of intelligent code suggestion. It's an interesting shift on programming language evolution - that the main productivity evolution is now in the supporting tools rather than the languages themselves.

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

A note from this newsletter's sponsor

News

Java performance tuning related news

• Announcing the JFR Event Collection website
• JDK 17 includes a JFR wizard for creating configuration files, and an option to configure directly from the jfr command. You can also set values from the command-line at startup, eg `java -XX:StartFlightRecording:allocation-profiling=high`
• New CRT HTTP Client in AWS SDK gives a faster startup time and lower memory usage (useful for AWS Lambdas)

Tools

Java performance tuning related tools

• JFR events, an up-to-date collection of all OpenJDK JFR events for every JDK
• Java agent to diagnose JDK-8180450 which leads to false sharing and scalability limitations in various types of inheritance hierarchy checks including using instanceof
• jsoniter (json-iterator), fast JSON parser

Articles

• Java Deadlock Prevention and Troubleshooting Tips - All You Got To Know (Tech Is Beautiful/Dev Genius)
• Quarkus Runtime performance - a peek into JVM internals (Franz Nigro, Luis Barreiro/Quarkusio)
• The Bias in Allocation Profiling (Kirk Pepperdine/kodewerk)

Jack Shirazi

Back to newsletter 268 contents