We REALLY nead a NON-PCH build in JPRT NOW!

Erik Joelsson erik.joelsson at oracle.com
Thu Apr 9 08:02:53 UTC 2015

On 2015-04-03 22:32, Dmitry Samersoff wrote:
> Kim,
> On my experience PCH significantly slow-down ccache-enabled build.
> Probably because ccache requires some tricks to work with PCH
> see: http://ccache.samba.org/manual.html#_precompiled_headers
Historically, this is true, but I fixed this rather recently in 
configure so that ccache uses the correct configuration for PCH, when 
PCH is enabled. So if you think it could help, I would urge you to retry 
ccache, but use a recent version. Still, both techniques work better 
alone than together and should be used to match your use case.

On my linux workstation (32 virtual cpus including HT), using the Oracle 
internal offical devkits (gcc 4.8.2) for building, my build is faster 
without PCH. I recently did work on a mac (while working on the new 
hotspot makefiles) and when I got PCH to work, build times for just 
Hotspot went from 18 minutes to 6 minutes, using clang, Xcode 5.1.1 and 
JOBS=2. The mac in question is a standard Stockholm JPRT mac, so in that 
case, PCH very much helps build times in JPRT.

The problem with ccache in Hotspot is that when you change a header 
file, most of the time, most of the cache is invalidated. This is 
because most header files are included in most cpp files. Because of 
this, using ccache in JPRT has been deemed pointless. This is also why 
PCH tends to help full builds for Hotspot, as a large part of the code 
is saved from being compiled over and over.

I think that as long as we claim to support building both with and 
without PCH, the automatic testing should test both with and without 
PCH. By adding one or two build targets, or perhaps change an existing 
target, we could increase our test matrix to cover this easily.


> -Dmitry
> On 2015-04-03 01:36, Kim Barrett wrote:
>> On Apr 2, 2015, at 12:06 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>> while precompiled headers (PCH) are a nice and effective way of
>>> improving hotspot build times
>> Are we sure about that?
>> Earlier today I ran into a local build failure that appeared to me to
>> be possibly PCH-related.
>> So I decided to try disabling PCH, since I now know about the option
>> for doing so, from Volker's email.  But I wanted to see how much
>> slower my build times would be.
>> Imagine my surprise when disabling PCH made my clean builds 10-15%
>> *faster*.  This is for a full jdk root "make images" build, which
>> makes that much of a difference even more astonishing, because there's
>> a lot more going on there than just compiling Hotspot.
>> So how sure are we that PCH (or perhaps the way we are using it)
>> provides any positive benefit at all?  I'm pretty sure it's not doing
>> anything good for me.
>> For reference, my build configuration is Ubuntu 14.04 x86_64,
>> reporting 24 processors.  My configure options are
>>    --enable-ccache
>>    --with-debug-level=release
>>    --disable-zip-debug-info
>>    --disable-precompiled-headers     -- new
>>    --with-jobs=24
>> I made sure to clear the ccache between each build.

More information about the hotspot-dev mailing list