On Wed, 12 Aug 2026 13:58:27 GMT, Erik Joelsson <[email protected]> wrote:
> The Hotspot source has, at least historically, had a pretty large amount of > global header files that are included in almost every compilation unit. Ah, yes, I had forgotten about that. I can confirm that even isolated changes to key header files (e.g. c2_global.hpp) pretty much triggers a full libjvm.so re-compilation. > 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? Oh, to be clear, I'm not advocating for central caches. I believe the build caches can be made specific to the branch name and the PR author's identifier (or any other identifier) without sharing across PRs, based on how we construct the cache key (see https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching#cache-key-matching); the impetus being that when authors have to tack on new commits to their PRs in response to review comments, they'd get faster feedback due to (hopefully) incremental builds. I'm happy to go dig into this and run some experiments to confirm/disprove the hypothesis if that'd be helpful. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32059#issuecomment-5270731057
