HotSpot just got Hotter - IcedTea6 support for latest HotSpot

[Andrew John Hughes]

On 02/12/2008, Mark Wielaard <mark at klomp.org> wrote:
> On Tue, 2008-12-02 at 09:37 +0000, Gary Benson wrote:
>  > Mark Wielaard wrote:
>  > > I think that supporting more than 2, lets call them "stable" and
>  > > "latest", might be a bit ambitious.  We risk having to try to keep
>  > > up with all the different versions and duplicating all our patches
>  > > against more and more versions.
>  >
>  > I'd extend this and say can we not just support one?  When Andrew said
>  > he was doing this last Thursday, my original thought was "great, we
>  > can get rid of all this two-versions-of-HotSpot stuff", so the thought
>  > of not only retaining it but possibly adding more is... unpleasant.
>  >
>  > My biggest issue was that, when there were problems with patches where
>  > there were two versions of something -- usually because of a new
>  > OpenJDK build -- people would often just fix one version and leave the
>  > other.  So I'd wake up in the morning and suddenly my stuff wouldn't
>  > build and I'd spend all day making a fix that turned out to have
>  > already been applied in the "other" HotSpot.  This is why I developed
>  > Shark out of the main tree fwiw.  It was easier for me to deal with a
>  > huge dislocation every month or so -- when I was ready for it -- rather
>  > than potentially every day.
>
>
> Yeah. So it might be good to better write down the requirements and
>  reasons to make hotspot upgrading easier:
>
>  - The current hotspot on openjdk6 is just too old, we keep adding more
>  and more backported patches for crasher bugs that we know are fixed in
>  later versions or build fixes for newer/older toolchains on gnu/linux
>  distros (we are carrying about 25 such patches now, excluding the sparc,
>  zero and shark work).

When I merge this patch, this won't be the default any more.  If
someone wants to continue to maintain it, then they are welcome to
step up and do so.  But I expect main dev. effort to go to the OJ7
HotSpot now.

>  - The build setup of hotspot in openjdk6 is different from the main
>  hotspot repo (make versus build). This is causing a lot of the pain of
>  maintaining the zero/non-zero (7b24/6b13) divergences. Andrew tries to
>  make this work a bit easier with his HOTSPOT_MAKE_DIR addition. But
>  ideally we would only support hotspots with the newer build dir setup.

I don't think it's much more than a name change.

>  - We want an easy mechanism for trying out newer hotspots so you can
>  easily build a newer version and let people try out performance
>  improvements or new features/flags (but on top of the stable 6 core
>  build). I really like this part of Andrew's patch, which lets you select
>  either a hg revision/version number or a prepackaged hotspot src zip.

Indeed; the HotSpot src zip can be anything you want really.  You just
have to get the patches to apply :)

>  - We want to support the linux/sparc bits (the various
>  icedtea-sparc-*.patches). Some of this is actually already in newer
>  hotspots.

Already handled:

if !WITH_ALT_HSBUILD
ICEDTEA_PATCHES += \
        patches/icedtea-hotspot7-tests.patch \
        patches/icedtea-sparc.patch
endif

The main big SPARC patch is not applied for 7.

>  - We want to support zero/shark. Ideally without having to have separate
>  sets of ZERO_PATCHES and NON_ZERO_PATCHES (all our NON_ZERO_PATCHES are
>  actually rebases of ZERO_PATCHES to older hotspot versions). This
>  requires a hotspot that includes at a minimum the C++ interpreter.
>

Are ZERO_PATCHES patches which enable the Zero build (that's what I
assumed) or just OJ7 patches? If they are the latter, we should have
been applying them to 7.

>  What is the best way to combine all these properties and keep our
>  maintance level as low as possible. Which hotspot version(s) to support
>  by default that make it easy to provide support for all of the above
>  requirements. Did I forget anything?
>

I suggest supporting one HotSpot version across both IcedTea6 and 7.
I don't see a good reason to go for the slightly newer one Joe plans
to package over just using the latest, but it does sound like we will
be stuck in the same situation of backporting again.  This won't be as
new as Gary's b24 one even (which is hs12 IIRC).

>  Cheers,
>
>
>  Mark
>
>


-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8