Is the "skip boot cycle" trick still needed?

[Andrew Hughes]

----- Original Message -----
> I agree with Jon.  SKIP_BOOT_CYCLE=false has been a useful and handy
> test case (building JDK with the newly built JDK) to catch issues
> early
> on.    Such functionality makes it easy and convenient to do the skip
> boot cycle build via JPRT or our automated nightly builds.  FWIW -
> skip
> boot cycle build has been especially useful for Jigsaw as there are
> significant changes to the layout as well as the runtime and we do
> that
> in our nightly builds.
> 
> Mandy
> 
> On 9/10/2012 8:09 AM, Jonathan Gibbons wrote:
> > Using SKIP_BOOT_CYCLE=false has often flushed out bugs, and I would
> > be
> > concerned about its removal.
> >
> > Is it really that hard to provide the same functionality in the new
> > build system?  Surely, it should just be a matter of a couple of
> > recursive makes at the top-level, the first into an "interim" build
> > dir and the second using the result of the first as its
> > ALT_BOOTDIR.
> >
> > -- Jon
> >
> >
> > On 09/10/2012 04:43 AM, Magnus Ihse Bursie wrote:
> >> In the old system, one can set the oddly named SKIP_BOOT_CYCLE to
> >> false (which, internally, sets the slightly more clearly named
> >> DO_BOOT_CYCLE=true). This causes the product to build twice, the
> >> second time using the first build result as the boot jdk.
> >>
> >> This has been used, as I understand it, as a "poor mans
> >> integration
> >> test" -- if the build output could perform the feat of compiling
> >> the
> >> JDK, then it can't be that broken.
> >>
> >> This kind of behaviour is not implemented in the new build system,
> >> and I propose that it should not be. The cost for implementing
> >> this
> >> is that all build system for all builds will be more complicated,
> >> but
> >> the gains are more unclear. To me, this is just a test, and it's a
> >> bit odd to have that as part of the build system. I also believe
> >> are
> >> now far better tests using jtreg, and if they are lacking -- then
> >> the
> >> tests should be improved, not the build system changed.
> >>
> >> Is there anyone who would be protesting if the SKIP_BOOT_CYCLE
> >> functionality would be dropped in the new build system?
> >>
> >> /Magnus
> >
> 

I'd like to see it kept too.  Part of IcedTea (which works as a build system
on top of OpenJDK) does the same thing; in fact, it's the default and I wasn't
aware that OpenJDK had the same option until it came up in conversation with Kelly.

Personally, I don't push an update to IcedTea unless a full bootstrap has been completed.
I've seen it point out too many issues not to do so.  It's very possible that the
build finished but the VM won't even fire up.  This would be caught at build-time if
a boot cycle was done.

Yes, jtreg tests would catch this too, but they take more time & configuration than a
simple second build, plus there are tests that are known to fail and areas that aren't tested.
The build hammers a JDK pretty well, as we've found from getting gcj to do it!

One particular issue is with the way the OpenJDK build is structured.  I don't know if this
has changed in the new build but I doubt it.  Because langtools, corba, jaxp, jaxws & hotspot
are built before the jdk on a full build, they inherently build against the bootstrap VMs
version of classes they depend on (including some internal com.sun.* & sun.* classes).
So the second build will build these against the latest versions rather than the bootstrap
versions, effectively giving a free test that the JDK can still build itself as well.  We
spotted this in working on IcedTea, as obviously the internal classes aren't present on
non-Sun/Oracle JDKs so the build had to patched to use the JDK source code.

We also recently hit this problem in the opposite direction, where 7u has obviously been bootstrapped
with itself, but not 6: http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-September/004262.html

So the best builds, IMO, are ones that bootstrap with JDK n-1 (6 with 7, 7 with 8), then do a second cycle
with themselves.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07