Hotspot Express (HSX)

Fri Feb 28 11:29:43 UTC 2020

Hi Jesper,

thanks for your thoughts. They are definitely helpful for the
discussion. Please find my answers/comments inline:

On Wed, Feb 26, 2020 at 10:16 PM Jesper Wilhelmsson
<jesper.wilhelmsson at oracle.com> wrote:
>
> 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?
>

My answer to this is yes, because we've actually done it for many
years (as mentioned before, with SAP JVM), and our users where quite
happy about it :)

Users usually want both at the same time, all the new shiny features
but with full backward compatibility so they don't have to change any
of their running applications. We all know that's impossible. But what
are the current alternatives? You can take a new Java release every
six month with just one month of overlapping support. Everybody who is
seriously using Java in production knows that this is impossible.

Some people claim that there are no more major Java releases since
Java 9 and every new feature release (i.e. 10, 11, 12, etc.) is
nothing more than a normal update release like 8u20, 8u40, etc in the
old Java 8 days. In my opinion, such a claim is simply ridiculous,
because most of the 10, 11, 12,.. releases are source and binary
incompatible with the previous release (e.g. because the removal of
the Corba, EE modules, Nashorn, new keywords, new class file versions,
the removal/renaming/hiding of internal classes, etc). It doesn't
matter if these incompatibilities are touching areas covered be the
Java SE specification of not - what matters is that no application
running on Java <n> is guaranteed to compile/run on Java <n+1> without
any modification. Such problem clearly never happened in update
releases like 8u20, 8u40, etc in the past.

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

What you write is of course true. But these are not source or binary
incompatible changes (and if such should exists, it would be the job
of the HSX project to work them around). Also, if a new JVM changes
some defaults, it would again be up to the HSX project to decide if it
will use the same, changed defaults or remain with the old ones. As an
example, HSX would probably not change the default GC but still give
the users of HSX the possibility to use a new GC which they wouldn't
have otherwise (a HSX project could even maintain a GC removed from
the latest JVM for some additional amount of time). On the other hand,
changing the MaxInlineDepth would be probably a changed default which
could be safely adapted by HSX after careful testing. For example in
SAP JVM, we never changed the default GC in older releases, but we
gave users of Java 5/6 the possibility to use G1, which they wouldn't
have had otherwise because downporting G1 would have been impractical
if not impossible.

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

That's all true. But in the end one has to decide what's cheaper, more
efficient and more attractive for the users: regularly downporting
hundred of bugfixes and maintaining big features like Shenandoah or
GraalVM in several major JDK versions in parallel or maintaining a HSX
version of the current JVM which gives you all the fixes and new
features for free.

I just want to re-iterate one more time:
 - this proposal is not about changing jdk tip or jdk tip development
 - it's also not about changing how the updates project is run

The proposal is about evaluating the advantages and drawbacks of HSX
in a new  project. It would be nice to have such a project under the
OpenJDK umbrella, but if nobody is interested at all, it can just as
well be developed independently.

Best regards,
Volker

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