persistent-cache

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[WiP] Explicitly declare different Gradle distributions for testing

  1. … 123 more files in changeset.
[WiP] Explicitly declare different Gradle distributions for testing

  1. … 122 more files in changeset.
Remove runtime only dependencies to :runtimeApiInfo and :apiMetadata

These are in the core of the Gradle distribution and should always

be available at runtime.

  1. … 67 more files in changeset.
Fix potential NPE if code is executed concurrently

Fix potential NPE if code is executed concurrently

Fix potential NPE if code is executed concurrently

Fix potential NPE if code is executed concurrently

Fix potential NPE if code is executed concurrently

Upgrade JUnit version (#12924)

Upgrade JUnit to 4.13, JUnit platform to 5.6.2

  1. … 331 more files in changeset.
Convert buildSrc to included build and precompile shared code quality plugins

  1. … 886 more files in changeset.
Upgrade JUnit

  1. … 330 more files in changeset.
Fix deprecation warning

  1. … 3 more files in changeset.
Fix deprecation warning

  1. … 3 more files in changeset.
Fix verification data

  1. … 5 more files in changeset.
Apply 'strict-compile' plugin to all subprojects

- Do not apply it anymore to GroovyCompile, as we have almost

no Java classes in Groovy folders left in production code

- Add more 'ignore' options for projects that can not easily made

strict for now

  1. … 24 more files in changeset.
Apply 'strict-compile' plugin to all subprojects

- Do not apply it anymore to GroovyCompile, as we have almost

no Java classes in Groovy folders left in production code

- Add more 'ignore' options for projects that can not easily made

strict for now

  1. … 24 more files in changeset.
Activate 'strict-compile' for all subprojects

  1. … 150 more files in changeset.
Update wrapper

  1. … 1 more file in changeset.
Apply the 'classycle' plugin consistently to all projects (#12849)

Existing cycles are now explicitly excluded in the corresponding

build scripts and are thus more visible. They may or may not be

improved on when working on the corresponding project.

  1. … 90 more files in changeset.
Fix memory leak in component metadata rule executor

The cross-build cache for cached component metadata rules stores

instances of realized Maven/Ivy module metadata in memory. The

problem is that those instances shouldn't have any state from

the project/Gradle build attached to them (they should be good

old POJOs) but for implementation reasons, they are not. In

particular, they keep a reference to the attributes factory,

which in turn keeps a reference to the object factory, which,

itself, will leak classloaders.

As a consequence, as more builds get executed, it was _possible_

that the cache would release some entries, but for the classloaders

to be released, it would require _all_ the entries from the same

build to be released from the cache. It turns out this event is

unlikely and as a consequence, builds end up running out of

memory.

This commit fixes the problem by making sure that at the end of

a build, we clear the in-memory cache of component metadata rules.

Therefore, cross-build, we would still read the result of the

execution of rules from the binary, on disk cache, but we would

not reuse in-memory results from previous builds.

This fix has been tested and validated by a user facing this

issue. Memory usage dropped from 11GB of memory to 1GB.

  1. … 14 more files in changeset.
Fix memory leak in component metadata rule executor

The cross-build cache for cached component metadata rules stores

instances of realized Maven/Ivy module metadata in memory. The

problem is that those instances shouldn't have any state from

the project/Gradle build attached to them (they should be good

old POJOs) but for implementation reasons, they are not. In

particular, they keep a reference to the attributes factory,

which in turn keeps a reference to the object factory, which,

itself, will leak classloaders.

As a consequence, as more builds get executed, it was _possible_

that the cache would release some entries, but for the classloaders

to be released, it would require _all_ the entries from the same

build to be released from the cache. It turns out this event is

unlikely and as a consequence, builds end up running out of

memory.

This commit fixes the problem by making sure that at the end of

a build, we clear the in-memory cache of component metadata rules.

Therefore, cross-build, we would still read the result of the

execution of rules from the binary, on disk cache, but we would

not reuse in-memory results from previous builds.

This fix has been tested and validated by a user facing this

issue. Memory usage dropped from 11GB of memory to 1GB.

  1. … 14 more files in changeset.
Fix memory leak in component metadata rule executor

The cross-build cache for cached component metadata rules stores

instances of realized Maven/Ivy module metadata in memory. The

problem is that those instances shouldn't have any state from

the project/Gradle build attached to them (they should be good

old POJOs) but for implementation reasons, they are not. In

particular, they keep a reference to the attributes factory,

which in turn keeps a reference to the object factory, which,

itself, will leak classloaders.

As a consequence, as more builds get executed, it was _possible_

that the cache would release some entries, but for the classloaders

to be released, it would require _all_ the entries from the same

build to be released from the cache. It turns out this event is

unlikely and as a consequence, builds end up running out of

memory.

This commit fixes the problem by making sure that at the end of

a build, we clear the in-memory cache of component metadata rules.

Therefore, cross-build, we would still read the result of the

execution of rules from the binary, on disk cache, but we would

not reuse in-memory results from previous builds.

This fix has been tested and validated by a user facing this

issue. Memory usage dropped from 11GB of memory to 1GB.

  1. … 16 more files in changeset.
Apply the 'classycle' plugin consistently to all projects

Existing cycles are now explicitly excluded in the corresponding

build scripts and are thus more visible. They may or may not be

improved on when working on the corresponding project.

  1. … 90 more files in changeset.
Apply the 'classycle' plugin consistently to all projects

Existing cycles are now explicitly excluded in the corresponding

build scripts and are thus more visible. They may or may not be

improved on when working on the corresponding project.

  1. … 90 more files in changeset.
Spike invalidating in-memory cache at the end of a build

  1. … 16 more files in changeset.
Spike invalidating in-memory cache at the end of a build

  1. … 16 more files in changeset.
WIP

  1. … 3 more files in changeset.
WIP

  1. … 3 more files in changeset.
WIP

  1. … 3 more files in changeset.
Experiment with batch cache access worker