Stop using precompiled headers for Linux?

Thomas Stüfe thomas.stuefe at gmail.com
Thu Nov 1 11:51:22 UTC 2018


On Thu, Nov 1, 2018 at 12:05 PM Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
>
> On 2018-11-01 11:54, Aleksey Shipilev wrote:
> > On 11/01/2018 11:43 AM, Magnus Ihse Bursie wrote:
> >> But then again, it might just signal that the list of headers included in the PCH is no longer
> >> optimal. If it used to be the case that ~100 header files were so interlinked, that changing any of
> >> them caused recompilation of all files that included it and all the other 100 header files on the
> >> PCH list, then there was a net gain for using PCH and no "punishment".
> >>
> >> But nowadays this list might be far too large. Perhaps there's just only a core set of say 20 header
> >> files that are universally (or almost universally) included, and that's all that should be in the
> >> PCH list then. My guess is that, with a proper selection of header files, PCH will still be a benefit.
> > I agree. This smells like inefficient PCH list. We can improve that, but I think that would be a
> > lower priority, given the abundance of CPU power we use to compile Hotspot. In my mind, the decisive
> > factor for disabling PCH is to keep proper includes at all times, without masking it with PCH. Half
> > of the trivial bugs I submit against hotspot are #include differences that show up in CI that builds
> > without PCH.
> >
> > So this is my ideal world:
> >   a) Efficient PCH list enabled by default for development pleasure;
> >   b) CIs build without PCH all the time (jdk-submit tier1 included!);
> >
> > Since we don't yet have (a), and (b) seems to be tedious, regardless how many times both Red Hat and
> > SAP people ask for it, disabling PCH by default feels like a good fallback.
>
> Should just CI builds default to non-PCH, or all builds (that is, should
> "configure" default to non-PCH on linux)? Maybe the former is better --
> one thing that the test numbers here has not shown is if incremental
> recompiles are improved by PCH. My gut feeling is that they really
> should -- once you've created your PCH, subsequent recompiles will be
> faster.

That would only be true as long as you just change cpp files, no? As
soon as you touch a header which is included in precompiled.hpp you
are worse off than without pch.

> So the developer default should perhaps be to keep PCH, and we
> should only configure the CI builds to do without PCH.

CI without pch would be better than nothing. But seeing how clunky and
slow jdk-submit is (and how often there are problems), I rather fail
early in my own build than waiting for jdk-submit to tell me something
went wrong (well, that is why I usually build nonpch, like Ioi does).

Just my 5 cent.

..Thomas
>
> /Magnus
>
>
> >
> > -Aleksey
> >
>


More information about the build-dev mailing list