Stop using precompiled headers for Linux?

[Erik Joelsson]

On 2018-11-01 08:17, Magnus Ihse Bursie wrote:
> On 2018-11-01 15:53, Ioi Lam wrote:
>> Just a stupid question. Does GCC have actual support for PCH? I know 
>> windows can load pre-compiled information from a special binary file. 
>> Does GCC support that kind of functionality?
> Yes.
>
> https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
>
But the Visual Studio compiler seems to be able to gain much more build 
performance from it. I don't have fresh numbers but I definitely 
remember a non PCH build on Windows taking more than double the time, if 
not triple or quadruple.

/Erik
> /Magnus
>
>>
>> Thanks
>> Ioi
>>
>>> On Nov 1, 2018, at 5:09 AM, Magnus Ihse Bursie 
>>> <magnus.ihse.bursie at oracle.com> wrote:
>>>
>>>
>>>
>>>> On 2018-11-01 12:51, Thomas Stüfe wrote:
>>>> 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.
>>> I hear you, loud and clear. :) I've created 
>>> https://bugs.openjdk.java.net/browse/JDK-8213241 to disable PCH by 
>>> default, for all builds, on gcc. (I'm interpreting "linux" in this 
>>> case as "gcc", since this is compiler-dependent, and not OS dependent).
>>>
>>> /Magnus
>>>
>>>> ..Thomas
>>>>> /Magnus
>>>>>
>>>>>
>>>>>> -Aleksey
>>>>>>
>