On Thu, Nov 1, 2018 at 12:05 PM Magnus Ihse Bursie <magnus.ihse.bur...@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 > > >
