Stop using precompiled headers for Linux?

[Magnus Ihse Bursie]

On 2018-11-02 17:21, Erik Joelsson wrote:
> Nice work!
>
> What exactly are you measuring, "make hotspot" or some other target?
Yes, "make hotspot".

> If we can find a reasonable set of extra files for the windows pch 
> that restores all or most of the performance, that would of course be 
> preferable. I doubt we will find a significantly better selection on 
> Mac compared to Linux though.
It seems the best selection for Mac more or less exactly equals Linux. 
Which is nice. For Windows, I was able to more or less precisely match 
the original behaviour with the Linux set + the four inline.hpp files I 
removed for Linux:

# include "oops/oop.inline.hpp"
# include "memory/allocation.inline.hpp"
# include "oops/access.inline.hpp"
# include "runtime/handles.inline.hpp"

Then I got from the original:
real    6m39.035s
user    0m58.580s
sys     2m48.138s
hotspot with original pch

to:

real    6m18.645s
user    0m55.963s
sys    2m28.264s
hotspot with new pch, BKM (on and above 130), including inline

Quite good for just adding four more files depending on the Windows 
platform.

By adding yet some more include files (and keeping the inline files), I 
was able to improve Windows compile time somewhat more:
real    6m7.355s
user    0m55.718s
sys    2m26.153s
hotspot with new pch on and above 110, including inline

Then I also added this set:
// 130-110
# include "runtime/thread.inline.hpp"
# include "utilities/bitMap.inline.hpp"
# include "oops/arrayOop.inline.hpp"
# include "gc/shared/gcId.hpp"
# include "runtime/mutexLocker.hpp"
# include "oops/objArrayOop.inline.hpp"
# include "classfile/javaClasses.inline.hpp"
# include "memory/referenceType.hpp"
# include "oops/weakHandle.hpp"
# include "oops/compressedOops.inline.hpp"
# include "gc/shared/barrierSet.hpp"
# include "utilities/stack.hpp"
# include "gc/g1/g1YCTypes.hpp"
# include "memory/padded.hpp"
# include "logging/logHandle.hpp"

This starts to look a bit specialized (the g1 files is likely to need 
#ifdef guards etc), so maybe it's not worth it.

/Magnus



>
> /Erik
>
>
> On 2018-11-02 07:00, Magnus Ihse Bursie wrote:
>> On 2018-11-02 12:14, Magnus Ihse Bursie wrote:
>>> Caveats: I have only run this on my local linux build with the 
>>> default server JVM configuration. Other machines will have different 
>>> sweet spots. Other JVM variants/feature combinations will have 
>>> different sweet spots. And, most importantly, I have not tested this 
>>> at all on Windows. Nevertheless, I'm almost prepared to suggest a 
>>> patch that uses this selection of files if running on gcc, just as 
>>> is, because of the speed improvements I measured. 
>>
>> I've started running tests on other platforms. Unfortunately, I don't 
>> have access to quite as powerful machines, so everything takes much 
>> longer. For the moment, I've only tested my "BKM" (best known method) 
>> from linux, to see if it works.
>>
>> For xcode/macos I got:
>> real    4m21,528s
>> user    27m28,623s
>> sys    2m18,244s
>> hotspot with original pch
>>
>> real    4m28,867s
>> user    29m10,685s
>> sys    2m14,456s
>> hotspot without pch
>>
>> real    3m6,322s
>> user    19m3,000s
>> sys    1m41,252s
>> hotspot with new BKM pch
>>
>> So obviously this is a nice improvement even here. I could probably 
>> try around a bit and see if there is an even better fit with a 
>> different selections of header files, but even without that, I'd say 
>> this patch is by itself as good for clang as it is for gcc.
>>
>> For windows I got:
>> real    6m39.035s
>> user    0m58.580s
>> sys     2m48.138s
>> hotspot with original pch
>>
>> real    10m29.227s
>> user    1m6.909s
>> sys    2m24.108s
>> hotspot without pch
>>
>> real    6m56.262s
>> user    0m57.563s
>> sys    2m27.514s
>> hotspot with new BKM pch
>>
>> I'm not sure what's going on with the user time numbers here. 
>> Presumably cygwin cannot get to the real Windows time data. What I 
>> can see is the huge difference in wall clock time between PCH and no 
>> PCH. I can also see that the new trimmed BKM list retains most of 
>> that improvement, but is actually somewhat slower that the original 
>> list. I'm currently rerunning with a larger set on Windows, to see if 
>> this helps improve things. I can certainly live with a 
>> precompiled.hpp that includes some additional files on Windows.
>>
>> /Magnus
>>
>>
>