Hard agree on the data waste, noise to signal ratio is typically very high and processing, shipping and storing all of that data costs a ton.
Previous start-up I worked on (jClarity, exited to Microsoft) mitigated much of this by having a model of only collecting the tiny amount of data that really mattered for a performance bottleneck investigation in a ring buffer and only processing / shipping and storing that data if a bottleneck trigger occurred (+ occasional baselines).
It allowed our product at the time (Illuminate to run at massive scale without costing our customers an arm and a leg or impacting their existing infrastructure. We charged on the value of the product reducing MTTR and not on how much data was being chucked around.
There was the constant argument against approach of always on observably or “collect all data JIC”, but with a good model (in our case something called the Java Performance Diagnostic Method) we never missed having the noise
Usual caveats of “you should run load to see if it’s truly wasted”, but we do know that Java defaults are not ideal out of the box and so we analysed a ton of workloads on Azure and came up with this: https://learn.microsoft.com/en-us/java/jaz - better defaults out of the box for the JVM in containers at runtime.
I wonder if statistically (hand waving here, I’m so not an expert in this field) the SOTA models do as much or as little harm as their human counterparts in terms of providing safe and effective emotional support. Totally agree we should better understand the risks and trade offs but I wouldn’t be super surprised if they are statistically no worse than us meat bags this kind of stuff.
This particular patch was upstreamed to OpenJDK tip and will be part of Java 22 for all vendors. We have back-ported the patch to our builds of 11, 17 (and shortly 21), and offer those back-ports upstream. However, those back-ports won't always be accepted into the stable LTS branches, so sometimes they'll only sit in our builds for those versions (like this patch in our 17.0.8+ builds). We make that clear in our release notes etc and the code is always available on our GitHub under the GPLv2+CE license.
The Microsoft Build of OpenJDK is very much a build of OpenJDK that Azure customers can get free support for and over time get some Azure specific performance benefits from. Those performance benefits will be worked on upstream as well (like this escape analysis patch was) but there will be times where upstream won't want to take a patch on a stable LTS branch for example. We'll continue to be very clear when we have a patch that is not in the upstream code and it'll always be available on our GitHub under the GPLv2+CE license.
I had the pleasure of working with Bob for a couple of years in the Java space formalising the thinking around Inversion of Control and dependency injection which was eventually standardised as JSR 330. His clarity of thinking, clean architecture and code are still exemplars that I send new Java engineers to go and learn from.
He was kind, took his time to explain things in way that the day to day developer could understand.
I’ll miss you crazy Bob, heart goes out to your family.
Chris was also well known in the London Java Community and contributed to multiple events, conferences, bringing his expertise in a thoughtful and kind way to folks who were often 1-2 stacks above the runtimes and compilers space .
My conversations with him about JVM design, GraalVM and Ruby were some of the most memorable and fun times I’ve had running around the conference circuit.
Thank you Chris for unselfishly sharing so much with us and leaving the world a better place, you will be missed.
The folks who work at Adoptium contain many OpenJDK committers (especially from Red Hat and Microsoft) so it does contribute back (but you’ll see folks using their company addresses). I agree that can confuse folks
TLDR: This can happen, but is not done much in practice.
Most vendors use pretty similar build toolchains in order to maintain platform support baselines. Typically any improvements get made at OpenJDK and then filter back down to downstream distributions.
One of the things we're looking to do is to add Metadata to the release to make the exact toolchain transparent going forward.
To be clear to everyone. Not commenting or promising on the future product direction of the Java server or Java edition (my group doesn't own the product or product direction in any way shape or form). There's just some stuff we can look at now to improve the status quo since a bunch of my team are also fans of the game :-)
Howdy, I’m the Group engineering manager for Java at Microsoft (yep we now do Java!). Our group is working on minecraft’s perf (starting with server) so expect a steady rate of improvement over the 2021
As rzwitserloot commented in Reddit's Java community:
Microsoft. This release is supporting a competitor in the OS space, who is shifting away from an ally on chip hardware, who also makes consumer electronics in direct competition with your hardware division, for a programming language which is in direct competition with your preferred language.
Previous start-up I worked on (jClarity, exited to Microsoft) mitigated much of this by having a model of only collecting the tiny amount of data that really mattered for a performance bottleneck investigation in a ring buffer and only processing / shipping and storing that data if a bottleneck trigger occurred (+ occasional baselines).
It allowed our product at the time (Illuminate to run at massive scale without costing our customers an arm and a leg or impacting their existing infrastructure. We charged on the value of the product reducing MTTR and not on how much data was being chucked around.
There was the constant argument against approach of always on observably or “collect all data JIC”, but with a good model (in our case something called the Java Performance Diagnostic Method) we never missed having the noise