How Microsoft contributes to Java - an Interview with Monica Beckwith
Sandra Ahlgrimm
Posted on November 6, 2020
Don't miss Rory Preddy, Java Advocate, interviewing Monica Beckwith - Java Champion and Principal Software Engineer at Microsoft.
You can watch the full interview on the embedded YouTube - Or you go with the summary, written by Sandra underneath.
Monica, tell us a little bit about yourself and your career so far!
Hi everyone! I'm Monica. I am a Java Champion and I work behind the scenes of your virtual machine. So basically, I work with HotSpot primarily, which is the OpenJDK virtual machine for Java. I've been doing stuff all the way from JIT compilation optimization of generated code and garbage collection performance improvements, especially with G1 GC (Garbage-First). That's my baby. And now I'm just looking at pretty much the entire HotSpot VM and improvements in the OpenJDK, that can benefit Azure as well as anything, any learning, any of first party, third party customers and their applications, their workloads, their use case patterns. That can benefit the OpenJDK ecosystem. To make it a win-win for everybody.
You said before the interview; You're not a Java developer. So tell me, how did you get into the Java Champion program?
I started my career with Java, but I was actually behind the scenes. So I started looking at OpenJDK. Back then, it was SunJDK like in 2002-ish. I was basically trying to understand how to optimize generated code. Back then X86-64(AMD64) was a new platform and it's a 64-bit platform. So what I was trying to do, is optimize the regenerative code and make sure, that we're using the right instructions - the pipeline up - so basically from the architecture, you're running Java code on. Back then, we just used some industry-standard benchmarks and we're going to make sure, that the underlying architecture can run and maybe like vectorization is an improvement we could do. We could get rid of redundant code. Also, try to speak the language of the underlying hardware architecture;
So optimizations for cache, prefetching all these things.
What's the best way to write a GC-optimized code?
I am always in awe of each program that I see out there. I never judge! I NEVER JUDGE. If you understand your allocations, if you understand the rate and the size of the objects, that's what matters! Right? In the end, you shouldn't worry about certain redundancies. It's my job. There are so many optimizations, that have gone into the JVM.
How would you describe Microsoft's role with the OpenJDK and the Java community?
I work on improving industry benchmarks and providing real-world use cases. This is a data-driven process where you find data patterns, and identify common cases.
How are the patterns for in-memory databases?
How does caching of caching affect different GC algorithms?
Why should we talk about G1 GC as which is the default GC?
Why should we keep our past times to this?
And that's, if you think about, before this job at Microsoft, that was kind of my goal in every job, that I did. There's got to be these defaults that will work for many people and that's, why they're called "Out of the box", because literally; You plug in your JVM, the GC that you get, the past time goals, that you get or whatever; It should work for average or even above average users out there. I always want to learn and improve the JVM. - So to speak.
Any further kind of news and exciting events, that you want to discuss on the JVM front?
Yeah, first of all, it's a big privilege for me. This opportunity is something, that you know people dream of. Where I see the future is; Java will always like the JVM is always going to evolve. Evolving into the next best thing out there. There's this vector API, that just is coming out as an incubator in JDK 16. We recently did a port to bringing Java to Windows ARM on Surface Pro X. Today, you can download the bits from Microsoft's GitHub repository.
The work was tracked under the JDK-8248496 item and has been delivered in OpenJDK 16. The work was later backported to JDK 11.
Source Code
Source code changes required to implement this port were tracked under JDK-8248238.
The port was merged into OpenJDK 16 and since then has been part of the OpenJDK mainline. Like previously stated, the port was later backported to JDK 11.
