On Tue, 11 Aug 2026 23:01:31 GMT, Ashay Rane <[email protected]> wrote:
> Related, has there been any discussion about enabling build caching for GHA? > Based on [JDK-8027584](https://bugs.openjdk.org/browse/JDK-8027584), it seems > like ccache was enabled for every build at some point in time, and I > understand the reasons for not going back to that, but do we have enough > confidence now to enable it in the GHA builds? Not that I know. The following is my, possibly dated, experience using ccache. The biggest native lib in the JDK is Hotspot. The Hotspot source has, at least historically, had a pretty large amount of global header files that are included in almost every compilation unit. Because of this ccache is rarely a net win for Hotspot developers as they tend to make changes to these header files quite often, invalidating most of the cache. There is also a significant overhead when running with ccache against an invalid or empty cache compared to running without it, so to get a net win, you need to hit the cache a lot. When I mostly worked in the build system years ago, this was perfect for me as I often needed to run clean builds and I never changed actual source code, just makefiles. In our distributed build and test systems, ccache wasn't able to provide value however, because it was too common for commits to touch global header files, and we only had machine local caches. With a central cache, the likelihood of getting a few builds that get a significant amount of hits goes up a lot, but it also adds more overhead interacting with the cache as it's now remote. My biggest argument against pursuing this for GHA however is security. How do we guarantee trust between all users of this cache? ------------- PR Comment: https://git.openjdk.org/jdk/pull/32059#issuecomment-5267813467
