Hotspot Express (HSX)

[Hohensee, Paul]

Re flags/features and compiler upgrades, my current HSX investigation covers delivering it only wrt to the latest LTS release, so I'm only thinking about 3 years, not forever, though process would the similar in the forever case.

When HSX was policy, flag and feature changes were handled much the same way they are now in JSX. I.e., deprecated and eventually removed, though physical removal was usually deferred to an LTS release. New features started out experimental, were default disabled until production ready, and when enabled, old flags became either nops or were translated to the nearest new equivalent. Once the new feature was in production and had possibly been made the default, we kept the now-deprecated old feature around for a transition period whose length varied with the feature. For CMS, I'd have proposed removing it in an LTS release: if people wanted it, they could use the previous LTS release, which would now be off HSX.

Timing of C++ compiler upgrades depends on whether it's just a toolchain upgrade or involves using new language features. Tool chain upgrades for tip aren't that big a deal (we're doing this already) and can be checked for in the most recent LTS release's makefiles: mostly they involve more-pedantic error checking, for which source changes are accepted by earlier versions. If the intent is to use more recent C++ language features, I'd propose allowing those only starting with an LTS release and provide lots of notice. Three year intervals seem to me short enough for this kind of change, though I realize some may disagree. If HSX were extended to earlier LTS releases, a potential solution would be to upgrade their tool chains, backport non-HSX source code changes as needed (i.e., to satisfy more-pedantic compilers), and restrict builds using old toolchains to security patches only (i.e., take them out of HSX).

Thanks,
Paul
 
On 2/21/20, 8:56 AM, "Claes Redestad" <claes.redestad at oracle.com> wrote:

    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