Stop using precompiled headers for Linux?

[Martin Buchholz]

I vote for disabling precompiled headers by default - they simply make the
build less reliable.

It seemed like precompiled headers did not work when using different
optimization levels for different source files, which in turn was needed
for building with clang, so I've been disabling precompiled headers for
years in my own build script.  Here's a snippet:

    # Disable optimization for selected source files.
    #
    # Needed to have different optimization levels for different files?
    addConfigureFlag --disable-precompiled-headers
    # We really need NONE; LOW is not low enough!
    # Fixed in jdk10: JDK-8186787 clang-4.0 SIGSEGV in Unsafe_PutByte
    ((major >= 10)) \
      || makeFlags+=(BUILD_LIBJVM_unsafe.cpp_OPTIMIZATION=NONE)
    if [[ "${DEBUG_LEVEL}" != "release" ]]; then
      # https://bugs.openjdk.java.net/browse/JDK-8186780
      makeFlags+=(BUILD_LIBJVM_os_linux_x86.cpp_OPTIMIZATION=NONE)
    fi


On Thu, 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
>>>>
>>>>
>