Hotspot Express (HSX)

[David Holmes]

On 20/02/2020 7:50 am, Hohensee, Paul wrote:
> 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.

There was concern when the new release model was announced that people 
would view the LTS releases as the "real" releases with the interim 
releases just being re-badged "update releases". Backporting everything 
to the last LTS release, or equivalently moving to a HSX model, just 
panders to that view and undermines the new release model in my personal 
opinion.

If you are prepared to use 11u with (nearly) everything from 13 (for 
example) backported into it, then why not just use 13?

> HSX does complicate the code base a bit, but is that worse than doing 600+ backports and counting? 

Yes it is worse. HSX impacts everyone working on the bleeding edge of 
JDK/JVM development. Backports are a cost to those who choose to make 
the backports only - that cost is high only because, again in my 
personal opinion, far too much is being backported.

With HSX, particularly within JSX, every change to the VM has to be made 
with consideration of whether this change will impact any previous 
release in an adverse way, and whether the change will need to be made 
conditional based on the version of the JDK used. The amount of baggage 
the VM has to carry and maintain just grows and grows, making the whole 
code base harder to understand and maintain. You'd need to run 
performance tests across all previous release before accepting any 
change - which is simply impractical.

> Also, I'm curious about how removing HSX remnants has improved performance. Can anyone point me at specifics?

By removing dynamic checks, simplifying and streamlining code.

Just my personal opinions having also worked on the previous HSX and its 
subsequent eradication (still ongoing).

Cheers,
David
-----

> 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
>      
>      
>      
>      
>