Microsoft announced a reaffirmation to contribute to the OpenJDK several months ago. As the details about the exact contribution were scant, InfoQ caught up with Martijn Verburg, principal group SWE manager, Java, and Bruno Borges, principal program manager, Java at Microsoft, about the specifics of the intended contribution from Microsoft to the OpenJDK.
Verburg and Borges talked about specific areas of contribution to the OpenJDK, especially in the areas of performance, Garbage Collection and so on, while still maintaining a flexible approach based on community needs. They provided more details about the Stack Allocation 'patch' -- a series of patches targeted at reducing object allocation rate of Java programs automatically by performing stack allocation of objects that are known to be local to a method.
InfoQ: Cloud-Native development has shifted to containers and polyglot development. Given that, how is the recent announcement related to Microsoft contributions to OpenJDK relevant to developers and architects?
Bruno Borges: Developers and architects who use Java around the world today are looking to move their Java workloads to cloud-native and container-based environments. Naturally, they still want to enjoy the various Java-based programming models, Java's strength in interoperability, and of course they want to continue to leverage the domain and technical expertise of their teams.
Microsoft supports these customers on Azure today -- e.g. on Azure Kubernetes Services (AKS), App Service, Big Data, Azure Spring Cloud, Functions and others -- and we will improve that experience by enhancing the underlying OpenJDK runtimes currently in use by these services, especially as it pertains to performance in cloud-native, container-based environments.
InfoQ: Can you outline some of the investments that Microsoft is planning to make in Java and OpenJDK for the benefit of all Java developers and users?
Martijn Verburg: Microsoft will be mainly investing time and technical expertise into OpenJDK's runtime performance; this includes, but is not limited to, cold startup time, warm start-up time, reduction in memory pressure (which reduces Garbage Collections and reduces footprint), improvements to various GC algorithms and auto-configuration of the JVM for certain types of workloads.
Microsoft will also be helping out in tooling and telemetry and is already looking to help with Java Flight Recorder and related features. We see tremendous potential with the new JEP 349 JFR Event Stream API.
InfoQ: At this point Microsoft seems to be taking a very flexible approach towards contribution. Can you comment a bit more on specifics, like in what areas does Microsoft want to make an impact with the OpenJDK? Are there any timelines? And are Microsoft engineers already working on parts of OpenJDK?
Verburg: Yes, we've delivered our first 4-5 patches into OpenJDK and are working closely with the stewards of Java (Oracle) and other major OpenJDK players (e.g. Red Hat and IBM) to identify where we can best collaborate to serve our customer's needs.
Here are some of those patches:
- 8236179: C1 register allocation error with T_ADDRESS
- 8231863: Crash if classpath is read from @argument file and the main gets option argument
- 8234076: JVM crashes on Windows 10 using --module=NAME
We're also working on a Stack Allocation 'patch'. This series of patches target reducing object allocation rate of Java programs automatically by performing stack allocation of objects that are known to be local to a method (or in compiler terms, 'non-escaping'). We're working through various industry benchmarks to make sure we haven't caused regressions and are also integrating some great suggestions by Oracle and other OpenJDK vendor VM engineers. We expect to raise a JDK Enhancement Proposal (JEP) for this work soon.
Primarily we're starting with small fixes and improvements to HotSpot (Garbage Collection, Just In Time compilation, etc), but once we have gained some more experience in working with OpenJDK and more importantly its community, we'll look to contribute more significant and impactful features.
InfoQ: Visual Studio has been around for decades, known and loved by developers. Is there a particular vested interest for Microsoft to contribute to OpenJDK and thereby enhance its own developer tools?
Borges: Microsoft invests in the Java extension for VS Code, which is proving to be extremely popular with Java developers who are building microservices and/or cloud-native applications. We will certainly continue to invest there.
InfoQ: GraalVM has been getting some attention lately amongst the Java community, and it also targets languages besides Java. Is Microsoft planning to work on GraalVM? Is there any intention to add language support for C#, for example?
Verburg: For us, it looks like GraalVM is at an early-stage technology and community when it comes to adoption among Azure customers, but we are watching it closely. We participated in its inaugural community workshop last year, and recently one of our engineers attended their summit in San Diego during CGO 2020 bringing great findings and learnings.
There’s been tremendous progress, and with the recent formation of their Advisory Board with several community members, we believe the project will gain more attention and potentially more adoption. We certainly look forward to be working with Oracle on it when the time comes.
InfoQ: What are the more exciting components of the OpenJDK (and the Java ecosystem) that the InfoQ audience should pay close attention to? Is there anything else to add to developers in general and Java developers in particular?
Verburg: The Road to Valhalla is of particular interest -- background and object model, is of particular interest. In Java 14 we have records coming in which is just one of the building blocks which will unlock a whole category of programming productivity improvements, as well as some serious performance enhancements.
In summary, Verjburg and Borges outlined specific areas that Microsoft will be focusing on for contributions to the OpenJDK, especially in the areas of performance and garbage collection, while still maintaining a flexible approach for the future-based on community needs.