On 2018-10-30 21: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.
Not long ago, the hotspot header files were a mess, so you almost always
ended up in recompiling all of hotspot regardless, when you changed a
header file. If this situation has improved, then certainly it might
have shifted the balance between gains and losses for PCH.
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.
/Magnus
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.
-Aleksey
