On Mon, 27 Jul 2026 21:29:43 GMT, Ashay Rane <[email protected]> wrote:

> This patch enables the `--enable-sccache` flag to enable build caching
> using sccache.  Specifically, if the toolchain is one among gcc, clang,
> or MSVC and if the sccache version is 0.10 and above, then the build
> prefixes all compiler invocations with the path to the sccache binary.
> 
> Since sccache is incompatible with ccache and precompiled headers, this
> patch makes the build fail if either ccache or precompiled headers are
> enabled in addition to sccache at the same time.
> 
> Validated this patch on {Linux, Windows, macOS} x {x64, aarch64}
> machines.  In the best-case scenario (i.e. when there are no changes to
> the source files), the time required to run the "make images" step is
> roughly cut in half.  Side note: the individual machines have very
> different configurations, so build times _across_ machines aren't
> comparable.
> 
> - Windows/x64: 2,107s -> 848s
> - Windows/ARM64: 1,264s -> 748s
> - macOS/x64: 808s -> 243s
> - macOS/AArch64: 480s -> 142s
> - Linux/x64: 225s -> 111s
> - Linux/AArch64: 364s -> 246s
> 
> ---------
> - [x] I confirm that I make this contribution in accordance with the [OpenJDK 
> Interim AI Policy](https://openjdk.org/legal/ai).

Thanks for taking a look, and my apologies for the delayed response.

> Do you find sccache better than ccache, other than the Windows toolchain 
> support?

No, other than Windows support, I have no reason to believe that sccache is 
qualitatively better than ccache.  I, too, am more familiar with ccache, so I'd 
prefer to get it working.  With the most recent version (4.13.2) available 
through MSys2, all compiler invocations seem to uncacheable:


== after first build ==

$ ccache --show-stats
Cacheable calls:       0 / 4329 ( 0.00%)
  Hits:                0
    Direct:            0
    Preprocessed:      0
  Misses:              0
Uncacheable calls:  4329 / 4329 (100.0%)
Local storage:
  Cache size (GiB):  0.0 /  5.0 ( 0.00%)

== after second build ==

$ ccache --show-stats
Cacheable calls:       0 / 6867 ( 0.00%)
  Hits:                0
    Direct:            0
    Preprocessed:      0
  Misses:              0
Uncacheable calls:  6867 / 6867 (100.0%)
Local storage:
  Cache size (GiB):  0.0 /  5.0 ( 0.00%)


Thanks also for your note about precompiled headers.  In the numbers that I 
posted, the first build has always been with caching enabled (whether through 
ccache or sccache) and with precompiled headers disabled.  I see your point 
that disabling precompiled headers would provide a misleading baseline.

Let me do two things.  First, I'll mark this PR as Draft until I can gather 
more measurements across different platforms with and without precompiled 
headers and after disabling caching (it might take me a few days).  And second, 
let me do some cursory inspection to find why ccache sees the cl compiler 
invocations as uncacheable.

At the risk of veering off on a tangent, is there an appetite for making the 
build use generators like CMake or Meson (to make the build both fast/native 
and easier to port across platforms)?  I know that the existing Make-based 
build is an acute problem only on Windows, thus increasing the inertia for 
change, but I wonder if this has been discussed before.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/32059#issuecomment-5254393666

Reply via email to