The AppD Approach: Java 9 Support

We are excited to announce full support for Java 9 as part of our Winter ‘17 product release. Java 9 introduces some interesting features such as incubator support for HTTP/2 and making the G1 Garbage Collector (GC) the default GC for the Java virtual machine (JVM). But the most fundamental change that impacted all Java performance monitors and profilers is its modularization support.

Specifically, Java 9 includes a feature called “Jigsaw” which provides support for the Java module system. The implementation of modules within the JVM presents unique challenges to our Java monitoring agent, as it further restricts access to packages, classes, and interfaces that we leveraged in earlier Java releases.

Good references to Java 9 modularization can be found here and here.

Here are the challenges posed by the Java modularization feature, and the stringent requirements we met to remain leaders in this space:

– The same binaries (jar files) should be used for Java 9 and older releases of Java. Users should not have to switch agent binaries or modify command line arguments when moving from one Java release to another.

– The user should not have to provide additional command line arguments for Java 9. A single command line argument, “-javaagent” is all that is required to introduce the Java agent into a JVM.

– Preserve support for dynamic attach by our agent into a running JVM.

– The implementation should be consistent with the ‘spirit’ of Java modularization. The monitoring agent should be defined as a named Java module.

– Access to restricted Java modules should be acquired dynamically, and should be limited to the monitoring agent module only. We should not create integrity or security exposures in the JVM by opening up access too broadly.

– Exploit modularization by allowing users to select Java methods for instrumentation based not only upon class and method name, but on module name as well.

During the initial design and implementation of modularization support within the monitoring agent, we were working with early drivers of Jigsaw, which, as it turned out, had a more restrictive set of features than those that eventually appeared in the GA release of Java 9. In the event that the more restrictive controls are put back in future releases of Java, the AppDynamics Java monitor should be ready.

Java Application Performance Monitoring was the first monitoring solution offered by AppDynamics, and is still one of its flagship products. We are committed to keeping pace with both our customers’ innovations and those in the Java ecosystem. With the implementation of our Java 9 support, we have again demonstrated that commitment. Our product not only provides tolerance and support for Java 9, but it also goes a long way towards exploiting the new capabilities that Java 9 offers.

Ryan TerBush is a co-author of this blog post. Ryan is a senior software engineer that has been with AppDynamics 2.5 years. He has an MEng degree in EE/CS from MIT. When he’s not fixing things at work, he’s most likely swimming or gaming.

What’s exciting about Java 9 and Application Performance Monitoring

In today’s modern computing age, constant enhancements in software innovations are driving us closer to an era of software revolution. Perhaps in the distant future, that may be how the 21st century is remembered best. Among the popular software languages out there, however, Java continues to have the largest industry footprint, running applications around the globe producing combined annual revenue in trillions. That’s why keeping up on the JDK is a high priority. Despite having a massive API to improve programming productivity, Java has also grown due to its high performance yet scalable JVM runtime, building among the fastest computing modern applications. As Java’s footprint expands, JDK innovations continue to impact billions of lines of code. As AppDynamics continues to grow, our focus towards supporting Java is only furthered by our customer use & industry adoption of the JVM.


Since the release of Java 8 in March of 2014, discussions around what’s next for Java 9 have begun to steadily grow. Although various JDK enhancements were originally targeted for Java 9, the scope of committed work has gradually narrowed with an upcoming proposed release date of Spring 2017. With over 30 key enhancements presently targeted, the ones with potential for broadest impact will be shared.

Project Jigsaw:

Among the largest impacting JDK 9 enhancements are from Project Jigsaw. Jigsaw’s primary goal is to make the JDK more modular whereby also enhancing the build system. It is motivated by the need for making Java more scalable for smaller computing devices, secure, performant, and to improve developer productivity. With the advent of the Internet of Things (IoT), enabling Java to run on smaller devices is instrumental for continued growth. However as Java’s footprint expands, its more prone to security targeting and performance issues as a nature of running on a vast permutation of computing services. Thus with a more modular JDK, developers can significantly reduce necessary libraries needed to build features, whereby reducing security risks as well as making the applications smaller with better performance (ie. improving code cache & class loader footprint, etc).

HTTP/2 Client: 

Among the most popular web protocols, HTTP has been getting its own upgrade to HTTP/2 (with inspiration from Google’s SPDY/2), boasting significant network performance gains. Hence, Java 9 will get its own HTTP client API implementing HTTP/2 and WebSocket to replace the legacy HttpURLConnection, which predates HTTP/1.1 and has various limitation such as the one thread per request/ response behavior. Using HTTP/2 in Java 9, applications will have better performance & scalability with memory usage on par or lower than HttpURLConnection, Apache HttpClient, and Netty.


Also being referred to as Java RPEL (Read-Print-Eval-Loop), JDK9 users will be getting a shell like interface to interactively evaluate declarations, statements, and expressions in Java. Similar to the Python or Ruby interpreters or other JVM languages like Scala and Groovy, Java users will be able to run Java code without needing to wrap in classes or methods, allowing for a much easier, faster learning & experimentation. Furthermore, as Java has been moving towards becoming a less syntactically verbose language with features like Lambda introduced in JDK 8 (shared in our Java 8 blog last year), having a shell-like interface becomes more practical for ad-hoc testing.

Screen Shot 2016-01-05 at 9.51.26 AM.png

The JVM Code Cache is critical to application performance and can be set at startup time using the following flag: -XX:InitialCodeCacheSize=32m. When the code cache memory is exhausted, the JVM losses JIT and goes into interpreted mode, significantly affecting application runtime performance. In Java 9, this section of memory is getting divided into the following 3 distinct heap segments in order to improve performance and enable future extensions: JVM internal (non-method) code, Profiled-code, Non-profiled code.

Notable mentions:

Some other notable changes in JDK 9 will include making the G1 collector default, adding a Microbenchmark testing suite extending the current JMH, and the removal of some aged unsupported performance tools such as JVM TI hprof and jHat.

Although most programming languages tend to come and go, Java is one that’s here to stay (least for the foreseeable decade). As one of the most popular and widely adopted languages with a high performant, scalable runtime, innovations towards the JDK have a large impact on the world’s computing infrastructure. By staying current with what’s in the next JDK, firms running JVM services can intelligently plan & prioritize their innovation initiatives that are complementary to languages improvements. For all those excited yet impatient and looking to get hands on, the latest JDK 9 builds can be accessible from here: