Hotspot Express (HSX)

[Jesper Wilhelmsson]

My personal experience from the hsx model was that it caused problems for several features we were implementing at the time. Features that actually needed to keep the JVM and the libraries in sync. That could be because we were porting a lot of the old JRockit stuff to Hotspot at that time, so there were several features that were more intrusive than the average JVM change - and there was simply a lot going on all over the place. (JFR was one of these features for instance.)

Since I'm not heavily involved in the updates project I don't really have an opinion on how you run it, but I do have an observation.

I find it interesting that so many experienced developers are willing to fend off all the changes that are done in the JVM as things that happen under the surface and won't be noticed by the users. Performance improvements is one thing - that you obviously want the users to notice, but all the other intricate details seems to be ignored in this discussion. Let's say there were no maintenance cost at all involved in hsx - the latest JVM could simply be plugged in to any old JDK - would you do it?

Changes in the JVM often have several observable effects. Faster execution can be one of them. But reordering of instructions, changes in cache behavior, NUMA behavior, locking schemes and thread synchronization, or even simple bugfixes can from time to time cause unexpected results in the execution of the Java application and even break code that deliberately or undeliberately depends on a certain unspecified behavior. Not to mention even more intrusive, deliberate changes in default values, default algorithms or even the existence of algorithms. Would an hsx model happily pick up a new JVM where the default GC was changed to G1, or where CMS was removed and plug it into a JDK 8 running in production out there?

The JVM isn't an isolated library that lives its own life without contact with the rest of the JDK. Changes in the JVM often go hand in hand with changes in the language. Which GC behaves the best depends on how the language is used and what kind of objects that fills the heap. This in turn depends heavily on what language features that are used. The same goes for the JIT compilers, different optimizations have different effect on the executed code depending on what language constructs are used in the Java application. The optimizations done in a JVM designed for JDK 15 is not necessarily the best choices for a JVM intended for JDK 11.

Just an observation.
/Jesper

> On 26 Feb 2020, at 17:12, Hohensee, Paul <hohensee at amazon.com> wrote:
> 
> And, when jdk17 ships, it would affect only jdk17u.
> 
> Paul
> 
> On 2/26/20, 1:50 AM, "jdk-updates-dev on behalf of Dalibor Topic" <jdk-updates-dev-bounces at openjdk.java.net on behalf of dalibor.topic at oracle.com> wrote:
> 
> 
> 
>    On 26.02.2020 01:16, Volker Simonis wrote:
>> The proposed HSX approach isn't gonna change this at all. It will always
>> use the latest released HS version in the current LTS JDK.
> 
>    Thanks for clarifying that your proposal would affect OpenJDK 11 Updates
>    only, Volker.
> 
>    cheers,
>    dalibor topic
> 
>    --
>    <http://www.oracle.com> Dalibor Topic
>    Consulting Product Manager
>    Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
>    <tel:+491737185961>, Video: dalibor.topic at oracle.com
>    <sip:dalibor.topic at oracle.com>
> 
>    Oracle Global Services Germany GmbH
>    Hauptverwaltung: Riesstr. 25, D-80992 München
>    Registergericht: Amtsgericht München, HRB 246209
>    Geschäftsführer: Ralf Herrmann
> 
> 
>