Stop using precompiled headers for Linux?

[Erik Joelsson]

Below are the corresponding numbers from a Mac, (Mac Pro (Late 2013), 
3.7 GHz, Quad-Core Intel Xeon E5, 16 GB). To be clear, the -npch is 
without precompiled headers. Here we see a slight degradation when 
disabling on both user time and wall clock time. My guess is that the 
user time increase is about the same, but because of a lower cpu count, 
the extra load is not as easily covered.

These tests were run with just building hotspot. This means that the 
precompiled header is generated alone on one core while nothing else is 
happening, which would explain this degradation in build speed. If we 
were instead building the whole product, we would see a better 
correlation between user and real time.

Given the very small benefit here, it could make sense to disable 
precompiled headers by default for Linux and Mac, just as we did with 
ccache.

I do know that the benefit is huge on Windows though, so we cannot 
remove the feature completely. Any other comments?

/Erik

macosx-x64
real     4m13.658s
user     27m17.595s
sys     2m11.306s

macosx-x64-npch
real     4m27.823s
user     30m0.434s
sys     2m18.669s

macosx-x64-debug
real     5m21.032s
user     35m57.347s
sys     2m20.588s

macosx-x64-debug-npch
real     5m33.728s
user     38m10.311s
sys     2m27.587s

macosx-x64-slowdebug
real     3m54.439s
user     25m32.197s
sys     2m8.750s

macosx-x64-slowdebug-npch
real     4m11.987s
user     27m59.857s
sys     2m18.093s


On 2018-10-30 14:00, Erik Joelsson wrote:
> Hello,
>
> On 2018-10-30 13:17, Aleksey Shipilev wrote:
>> On 10/30/2018 06:26 PM, Ioi Lam wrote:
>>> Is there any advantage of using precompiled headers on Linux?
>> I have measured it recently on shenandoah repositories, and 
>> fastdebug/release build times have not
>> improved with or without PCH. Actually, it gets worse when you touch 
>> a single header that is in PCH
>> list, and you end up recompiling the entire Hotspot. I would be in 
>> favor of disabling it by default.
> I just did a measurement on my local workstation (2x8 cores x2 ht 
> Ubuntu 18.04 using Oracle devkit GCC 7.3.0). I ran "time make hotspot" 
> with clean build directories.
>
> linux-x64:
> real    4m6.657s
> user    61m23.090s
> sys    6m24.477s
>
> linux-x64-npch
> real    3m41.130s
> user    66m11.824s
> sys    4m19.224s
>
> linux-x64-debug
> real    4m47.117s
> user    75m53.740s
> sys    8m21.408s
>
> linux-x64-debug-npch
> real    4m42.877s
> user    84m30.764s
> sys    4m54.666s
>
> linux-x64-slowdebug
> real    3m54.564s
> user    44m2.828s
> sys    6m22.785s
>
> linux-x64-slowdebug-npch
> real    3m23.092s
> user    55m3.142s
> sys    4m10.172s
>
> These numbers support your claim. Wall clock time is actually 
> increased with PCH enabled, but total user time is decreased. Does not 
> seem worth it to me.
>>> It's on by default and we keep having
>>> breakage where someone would forget to add #include. The latest 
>>> instance is JDK-8213148.
>> Yes, we catch most of these breakages in CIs. Which tells me adding 
>> it to jdk-submit would cover
>> most of the breakage during pre-integration testing.
> jdk-submit is currently running what we call "tier1". We do have 
> builds of Linux slowdebug with precompiled headers disabled in tier2. 
> We also build solaris-sparcv9 in tier1 which does not support 
> precompiled headers at all, so to not be caught in jdk-submit you 
> would have to be in Linux specific code. The example bug does not seem 
> to be that. Mach5/jdk-submit was down over the weekend and yesterday 
> so my suspicion is the offending code in this case was never tested.
>
> That said, given that we get practically no benefit from PCH on 
> Linux/GCC, we should probably just turn it off by default for Linux 
> and/or GCC. I think we need to investigate Macos as well here.
>
> /Erik
>> -Aleksey
>>
>