Hotspot Express (HSX)

[Claes Redestad]

On 2020-02-21 16:45, Volker Simonis wrote:
> I don't agree with what's been said in this thread before, namely that
> a strong coupling of VM and JDK "is good" for OpenJDK, helps
> accelerating the development and improves the performance. 

Let's agree to disagree.

The speed-up in OpenJDK mainline development I've witnessed over my 7
years working here has been remarkable. Of course removing hsx is only
partially to thank for this, but it's an important piece in a greater
scheme to remove impediments that would have been at odds with many
of the tougher decisions made over the past few years.

For example consolidated repositories have decidedly helped streamline
work, especially when needing to sync changes from jdk to hotspot and
vice versa. Of course you can have hsx in a consolidated world, but it
does work against you.

A more allowing stance on feature removals have also helped us shed
a lot of weight. Removing anything is bound to be a lot messier in a
world with hsx.

Not to mention java modules, the implementation for which I think would
have ended up much messier if the hsx model was retained.

> In contrary, I think it will lead to bad "ad-hoc" decisions and wrong
> dependencies which might be helpful for the moment but which introduce
> considerable maintenance costs in the long term.

 From my experience this seems unlikely, but yes, there will be fewer
checks against it.

As a counterpoint I believe most decisions are very mindful about
maintenance costs, to the point where reducing future maintenance cost
is usually the sole motivator - sometimes at expense of customer
convenience. See the removal of CMS, for example.

On that note, how _would_ this hsx project deal with features and flags
that are deprecated and removed from the mainline? Will you need to
resurrect removed features such as CMS, but hide the code behind build
flags..?

And looking further, how would hsx deal with a project like the C++
compiler upgrade[1], which will change system requirements and thus be
unsuitable for a backport?

/Claes

[1] https://openjdk.java.net/jeps/347