HotSpot Patching post-b14

[Andrew John Hughes]

Hi all,

You will recall that we switched to using HotSpot b14 recently.  As
you may have seen in my e-mails with Lillian, this has resulted in
some changes in the way patches are applied to HotSpot.  I'm sending
this e-mail in the hope of explaining this process and hopefully being
able to convince people to simplify things a little... ;)

When I ported IcedTea6 over to b14, the patches changed substantially.
 Basically, the following process was applied:

1.  Each patch was examined to see if they altered files in the hotspot tree.
2.  If they did, the patch was moved to patches/hotspot/original.  In
some cases, this meant splitting the patch so that there was a common
patch in patches and a HotSpot-specific part in
patches/hotspot/original.  This was the case with
icedtea-version.patch and hence the confusion when Lillian patched
this.
3. IcedTea7 was used as the source for HotSpot 14.0b08 patches.
Basically, the same copying/splitting of patches was applied using
IcedTea7's patches directory and the results placed in
patches/hotspot/14.0b08.

This means that for an original patch like icedtea-version.patch, 2
out of 3 patches are applied during a build in place of the original.
The one in patches is always applied.  The other patch to be applied
depends on the value of HSBUILD.  This defaults to 14.0b08 (i.e. the
new HotSpot).  Hopefully it's clear from this explanation that if you
add a HotSpot patch to the main shared patch, it will work on your
default run but may fail if --with-hotspot-build=original is used as
the patch will be applied to a different version of HotSpot.  If
instead it is placed with the 14.0b08 patches, it will only apply on
builds using this version of HotSpot.

The question now is which one do we maintain?  At present, most people
will be building and testing 14.0b08 as this is the default.  Testing
each HotSpot patch using a --with-hotspot=original build is obviously
going to be time consuming so we need to decide if it is worth
supporting this option.  If not, we should remove original.  The
hierarchical system will be left in place to give others the option of
playing around, but we would use the same process as before, except
HotSpot patches would be added to patches/hotspot/14.0b08.  A similar
hierarchical system has been applied for xrender, ecj and security
patches so it's not unique to HotSpot and I hope it makes the patches
directory more manageable.

Finally, with respect to IcedTea7, the change to HotSpot b14 in
IcedTea6 means they should now be able to more readily share patches
and in particular, Shark and Zero should apply identically to IcedTea6
and IcedTea7.  With this in place, the option becomes available for
Gary to base development in the upstream hotspot tree of the zero
project and we can just pull the version of HotSpot from there instead
of jdk7 as at present when a zero/shark build is required.

Hope that makes things clear!

So thoughts on dropping original?
-- 
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