Hotspot Express (HSX)
Hohensee, Paul
hohensee at amazon.com
Wed Feb 19 21:50:43 UTC 2020
Given your stance on backports and JSX adoption, I can see your point and even agree with it. The problem is that the vast majority of users don’t want to use JSX. That's definitely the case inside Amazon.
HSX does complicate the code base a bit, but is that worse than doing 600+ backports and counting? Also, I'm curious about how removing HSX remnants has improved performance. Can anyone point me at specifics?
Thanks,
Paul
On 2/19/20, 12:23 PM, "Claes Redestad" <claes.redestad at oracle.com> wrote:
On 2020-02-19 20:59, Hohensee, Paul wrote:
> It’s hard to argue for JSX and against HSX at the same time.:)
Quite the opposite: The existence of JSX, as you put it, makes HSX very
questionable since a new JDK will be available with short notice for
those users who need it. HSX made more sense in a world where the next
big JDK was up to three years away.
In my opinion, the rapid cadence makes backports of anything except the
most critical patches to enhance stability questionable - but I've heard
that's not an uncontroversial opinion. :-)
It's also easy to argue against HSX for many other reasons: it
complicates the code base, the QA effort is not at all lessened since
you still had to test every supported combination of JDK x HS (the more
complex code meant there were more places for code to hide, though), and
it ultimately goes against the goal of optimizing performance.
Why? Well, it means anything where the VM and JDK interacts need to use
dynamic linkage and extra check. Does this field exist in this java
class? Is this the layout of java.lang.String this time around? While
not hugely impactful, a great number of improvements to startup,
footprint and some throughput performance in the last few releases has
come from *removing* the remnants of HSX, as it existed in the past,
and I think the OpenJDK is better for it.
Please don't bring HSX back!
Thanks!
/Claes
More information about the jdk-updates-dev
mailing list