Microsoft’s enthusiasm for ARM processors with its availability on notebooks and lately in cloud environments, has been taken one step further. This summer, Microsoft made its first big contribution to OpenJDK: the first phase of porting OpenJDK to Windows 10 ARM (AArch64). Specifically, that means that one can develop and run Java code on Windows 10 ARM operating machines.
The porting effort was the first project led by Monica Beckwith since she joined Microsoft. InfoQ reached out to her and Martijn Verburg, principal SWE group manager for the Java Engineering Group, to explore more what this means for the Java community. Is it already possible to switch to a Surface Pro as your Java developing machine? Can we benefit from the performance of ARM processors on Azure?
InfoQ: Thank you for taking the time to answer some questions for our readers. Can we start by asking you to introduce yourselves and describe your roles and day-to-day at Microsoft?
Martijn Verburg: Hi all, I'm Martijn Verburg and I'm the principal SWE group manager for the Java Engineering Group at Microsoft. Some of you may know me previously from my role as CEO of jClarity (who MSFT acquired last year) or as one of the Steering Committee members at AdoptOpenJDK or at Jakarta EE. There are some rumors that I'm the "Diabolical Developer", but since I'm a manager that can't be true ;-).
Monica Beckwith: Hello, I am Monica and I am the lead of OpenJDK’s Windows on Arm64 project. My day-to-day work involves improving OpenJDK’s Hotspot VM. I have worked with OpenJDK since Sun started the project/effort back in 2006. I have mostly been working on the performance side of things working with optimizing the apps, the JVM, the GC heuristics, and making sure that the generated code sympathizes with the underlying hardware. Prior to Microsoft, I worked as the performance architect for managed runtimes at Arm.
InfoQ: This is the first big contribution from MS to OpenJDK. Why did you get started with ARM? Which was the most challenging problem to tackle? How did it go? What would you have done differently?
Verburg: Microsoft has two areas of interest with regard to ARM. Our Surface X Pro line runs on ARM hardware and in 2017 we announced our intent to trial ARM on our cloud infrastructure.
With regards to the challenges of the port, from my standpoint it was interesting to see the time and effort that the team spent on:
- Splitting up the patches into easily digestible chunks by the OpenJDK community (four patch sets in this case)
- Testing (functional, performance, and regressions of both)
When you're adding support for a new port there's the brand new code to add, and then (IMO) the more complicated reworking of the shared code. Doing no harm to what was already there (Linux aarch64) was really important to us, but it did take a lot of engineering cycles to get the patches right and to do the thorough testing on both platforms. It's the level of care and attention that makes me particularly proud of this group's efforts; they set a high bar for this sort of work. Kudos to Monica's leadership and the work of her team; they managed this from start to finish and were simply excellent.
Beckwith: Windows (10) enablement on Arm (WoA) is a big effort at Microsoft. Our first WoA offering for developers centered around the modern, cloud-based environment is the Surface Pro X device.
Arm64 has a rich ecosystem and with the introduction of Arm servers, it was clear that we needed to have a Java port to support our investment in "driving innovation with ARM server processors for use in our data centers".
Red Hat had already done a great job of porting OpenJDK to Linux on Arm64. Given our Windows developer base, it made sense to us to have the Windows port be our first big contribution to the OpenJDK ecosystem. We wanted to signal to the OpenJDK community that we were here to collaborate and help with the Java platform.
As for the most challenging part: I think when we started working on the port, we realized that we would be touching shared code in the linux-aarch64 code base as well as the windows-x86-64 code base. We wanted to make sure that we "minimized our ripple" since our goal was/is not only to push out the new platform support but also to support / cleanup / coalesce all that we touch.
As Martijn mentioned above, we are also heavily invested in a robust CI for tests and builds, and we wanted to make sure that we ran functional tests on all platform, combinations. We also run comparative performance and regression tests on windows-aarch64, linux-aarch64, and windows-x86-64 test platforms. For more details, please refer to the "Testing" section of JEP 388.
InfoQ: How did the community react to these contributions? Is AArch64 ready to be used by developers? If so, what are its limitations? Any advice for developers eager to get started using the AArch64 version?
Verburg: We were really pleased with the reaction. Across Reddit, Hacker News, and various Java community properties, the port was very well received. I think the telling comments were really about the quality of the patch (as stated by Andrew Haley, Red Hat's lead on the Linux Aarch64 port) and the general Java user public who were excited about the gaming opportunities :-).
Beckwith: We felt that we were greeted with open arms by the OpenJDK community, and the support provided to us in terms of review/feedback of our patches has been phenomenal! I personally feel humbled by the praise/coverage that we have received. The port itself is complete and we are in the process of enabling further features. Since Windows on Arm64 is a relatively new platform, we are also looking at the enablement of native components and similar dependencies - e.g. for Minecraft to run with our port, we need to ensure that LWJGL works on the new platform.
InfoQ: When would it be safe to presume that it will be safe to use in production environments? Are you using the platform for your efforts as well? If so, how does it feel?
Verburg: We're pretty conservative with our in-production recommendations. We have several quality milestones to get through before we declare production-ready:
- The code needs to be fully merged in OpenJDK jdk/jdk tip (i.e. Mainline)
- We need to complete the Technical Compatibility Kit (TCK) tests internally
- We need to make sure we're passing all of the AdoptOpenjDK Quality Assurance suites. We're already doing very well here
- We need to make sure we're able to run all of the important industry functional and performance benchmarks. I'm pleased to say that Monica, Ludovic, Bernhard, and the team have made great progress here as well.
All of the above is eminently achievable. We know what to do for all of them, it's just an engineering effort and some elapsed time before we get there.
We do "drink our own champagne" so to speak, but I can't comment more on that at this stage.
Beckwith: My mantra is "trust but verify". I apply it to any targeted performance improvements and any patches that we upstream. So, my humble advice is to verify how the port suits your environment and please provide feedback.
Now putting on my dev hat, I want to highlight that I have simple criteria to determine the status of this port - integration of the staging repo into the mainline and the port passing the TCK and AQA tests.
As for eating our own dogfood - yes! I can attest that it is yummy! One of my work and test systems is a Surface Pro X in a laptop setting and I am quite impressed with it.
InfoQ: Were there any benchmarks run during the OpenJDK release process? How does the ARM architecture behave in comparison with the others?
Verburg: A whole host was run; I was proud of how diligent the team was on this. I'll do a poor job of explaining the details compared to Monica, so over to her!
Beckwith: On top of the above-named tests, I also maintain a workload status page on our openjdk-aarch64 GitHub repo. Arm64 servers are very competitive and we have been seeing great results.
InfoQ: It seems that there is a gold rush towards ARM processors: Apple is shifting towards their own chip based on ARM and AWS released ARM servers some time back. What are the benefits of using it? Will Azure be supporting ARM servers as well soon?
Verburg: It's a potential reduction in power consumption per compute unit cost-saving (which in turn leads to a reduction in COGS) that's got the whole industry looking at this. We can't comment on specific Azure product direction at this stage, but it's safe to assume that Microsoft is looking at this carefully.
Beckwith: With the introduction of the Neoverse N1 cores (Arm 8.2 ISA), Arm has geared up nicely for the server/cloud market. Arm has traditionally supported a weaker memory model, which means that in a multi-core environment, when data accesses need to follow a defined order of program execution, software needs to step in and guarantee the execution order by including guards/barriers/fences in the code.
With platforms that support Arm 8.1+ ISA, we already are seeing improvements thanks to the new atomic instructions and in Neoverse we also see smart issuing of barriers (as in eliminating them altogether if deemed unnecessary). Apart from the above, we also see a reduction in power consumption and improvements in performance, thanks to the 7nm fab.
InfoQ: Martijn, jClarity was acquired by MS almost one year ago, with the declared purpose of helping optimize the Azure Java workloads. How was this past year for you and the other jClarity folks?
Verburg: It's been a heck of a ride! There have been challenges of learning new corporate systems, migrating from Google Docs and Slack to Office 365 and MS Teams. Building a common culture with the host of other Java VM, tooling, and infrastructure experts that we've bought in from around the world also took time. Team building across six different time zones brings its own challenges, but they're solvable given some creative thinking.
We've been able to continue pushing the jClarity vision of ML led performance diagnostics internally, and we're now able to impact the heart of Java with a full VM Engineering Group, so we're pretty happy that our original north star is continuing along with a wider scope for impact.
My advice to other start-ups being acquired is that it takes six to nine months to truly settle in and only then can you think about pushing forward at your previous pace (and then eventually exceeding it).
We've now hit that stage where we're moving really fast again and producing some amazing software, so I now personally feel that I'm back at the helm of a fast-moving start-up, but a very well resourced one that also understands how to do enterprise :-).
InfoQ: Martijn, what did jClarity’s acquisition by MS mean for the AdoptOpenJDK effort? Did it bring the cumbersome decision-making processes sometimes associated with corporations?
Verburg: Microsoft has a pretty clear policy that we're to be an equal partner at AdoptOpenJDK and not be an undue influence just because of its perceived size. To begin with, there was certainly some disruption as the whole jClarity team was caught up in starting their new roles.
However, things have now actually improved over and above how it was at jClarity as we can bring more people power to the project in infrastructure, build and test as well as some welcome Azure compute power! Adopt continues to be run by the do-ocracy of the steering committee and I'm glad to say nothing has been slowed down or tied up with big corporate red tape. As it turns out, Microsoft knows how to do open source pretty well these days and so we have been encouraged to keep doing what we're doing :-).
InfoQ: There are a bunch of other contributions from MS for OpenJDK; which one was the most difficult one to tackle technically?
Verburg: I think the Stack Allocation proposal and the Windows ARM 64 port are roughly equal in the effort/complexity department. They both represent deep dive Hotspot work, which requires great expertise and care in order to provide new benefits without regressions.
Beckwith: As Martijn has already pointed out, stack allocation is one of our bigger pieces of work. We are also looking at inlining improvements and other such JIT optimizations.
InfoQ: What are the next steps for the ARM port, and the group in general?
Verburg: For the ARM port, it now needs the final polish, a passing run on the TCK, and for the JEP to be targeted to a Java major version release. I suspect Monica can provide more interesting detail here!
The group in general will continue to work on improvements to OpenJDK which will have a positive impact on first and third-party Java workloads. We're looking at internal and customer workloads on Azure and subsidiaries such as Minecraft, and seeing where we can drive the most value. I'll stress that this work will continue to be presented upstream to the OpenJDK project; Microsoft is here to be a good citizen at OpenJDK, we're excited to be giving back to the wonderful community there!
We'll also be looking to integrate jClarity's IP around ML-based performance diagnosis into various Azure services, but there are no concrete product announcements around that just yet.
Last but not least, you'll also see more community outreach coming from us, including the continued backing of AdoptOpenJDK (moving to the Eclipse Foundation as Eclipse Adoptium) and a constant stream of articles, posts and material via our Java at Microsoft Blog and @javaatmicrosoft Twitter account.
Beckwith: Some of our bigger milestones are as follows:
- The merger of the staging repo into upstream and
- The identification of a JDK release to not only target but also fully integrate and deliver the Windows on Arm64 port
- We are also looking forward to achieving TCK compliance
Personally, I would also like to drive enablement around the native components for OpenJFX, Minecraft, and similar.
As for the group - we want to make sure we keep optimizing the JVM and above all integrate and align well with the Java/JVM roadmap especially when we can envision some of the beneficial ecosystems with project Panama, Metropolis, Valhalla - just to name a few.
