We REALLY nead a NON-PCH build in JPRT NOW! (original) (raw)

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#precompiledheaders 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.

/Erik

-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 x8664, 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