Hotspot Express (HSX)

Fri Feb 28 18:38:34 UTC 2020

Hi Volker,

On Fri, Feb 28, 2020 at 12:30 PM Volker Simonis <volker.simonis at gmail.com>
wrote:

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

Opinions differ :-) I personally think your retrospective is both a bit
rosy and not really applicable to the current situation in the OpenJDK.

Note that I only talk for personal self here, not for my team.

I remember when we first implemented the hsx model - I was one of the
original developers - and the reason we did this was because we had a huge
load of valuable in-house developments which we had no choice but to
provide on every release and - in that time, before the OpenJDK was a thing
- without a way to contribute upstream. We then felt we really had no other
choice. In that time, JDK upstream dev velocity was low, way lower than our
own development speed, and so the hsx model seemed like the lesser evil.

But we never really measured the costs hsx incurred. All we have is
feelings, and feelings differ a lot depending on how one was involved. My
personal feeling was that the costs were considerable, and often not
directly obvious and easily overlooked.

> Users usually want both at the same time,

This is a conjecture, unless we have numbers to prove this. How many of our
customers really want new features, and how many just want to be left
alone, have a stable JDK which gets important bug fixes and security fixes,
but would feel uncomfortable if they knew that a large part of their "old"
JDK is actually from the latest release - which by the nature of things has
seen less field hours than the old VM?

This is not an argument against hsx, but I argue that there exists those
two groups of customers, and we do not know how large they are.

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

I don't understand. Would a hsx model not have deep implications about
development at jdk tip? Whether or not we think about this in an own
project is irrelevant, unless I misunderstand things.

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

How? The hsx model imposes limits on the developers of jdk tip. How could
it live without their buy-in?

> Best regards,
> Volker
>
>
Cheers, Thomas

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