Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Upgrade JUnit version (#12924)

Upgrade JUnit to 4.13, JUnit platform to 5.6.2

  1. … 331 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.
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. … 20 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. … 20 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. … 22 more files in changeset.
Spike invalidating in-memory cache at the end of a build

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

  1. … 21 more files in changeset.
Force AbstractTestDirectoryProvider to use Class (#12431)

Closes https://github.com/gradle/gradle-private/issues/2988

This PR adds `className` to `AbstractTestDirectoryProvider` so there'll be no more `unknown-test-class`.

  1. … 393 more files in changeset.
Fix tests

  1. … 358 more files in changeset.
Initial steps towards a 2-stage dependency cache

This commit introduces the infrastructure required to get a 2-stage

dependency cache, consisting of a read-only, shareable cache and

a read-write local mutable cache.

The read-only cache would typically be mounted on Docker images.

Only infrastructure, no tests yet.

  1. … 77 more files in changeset.
Initial steps towards a 2-stage dependency cache

This commit introduces the infrastructure required to get a 2-stage

dependency cache, consisting of a read-only, shareable cache and

a read-write local mutable cache.

The read-only cache would typically be mounted on Docker images.

Only infrastructure, no tests yet.

  1. … 77 more files in changeset.
Initial steps towards a 2-stage dependency cache

This commit introduces the infrastructure required to get a 2-stage

dependency cache, consisting of a read-only, shareable cache and

a read-write local mutable cache.

The read-only cache would typically be mounted on Docker images.

Only infrastructure, no tests yet.

  1. … 77 more files in changeset.
Initial steps towards a 2-stage dependency cache

This commit introduces the infrastructure required to get a 2-stage

dependency cache, consisting of a read-only, shareable cache and

a read-write local mutable cache.

The read-only cache would typically be mounted on Docker images.

Only infrastructure, no tests yet.

  1. … 77 more files in changeset.
Initial steps towards a 2-stage dependency cache

This commit introduces the infrastructure required to get a 2-stage

dependency cache, consisting of a read-only, shareable cache and

a read-write local mutable cache.

The read-only cache would typically be mounted on Docker images.

Only infrastructure, no tests yet.

  1. … 77 more files in changeset.
Initial steps towards a 2-stage dependency cache

This commit introduces the infrastructure required to get a 2-stage

dependency cache, consisting of a read-only, shareable cache and

a read-write local mutable cache.

The read-only cache would typically be mounted on Docker images.

Only infrastructure, no tests yet.

  1. … 77 more files in changeset.
Initial steps towards a 2-stage dependency cache

This commit introduces the infrastructure required to get a 2-stage

dependency cache, consisting of a read-only, shareable cache and

a read-write local mutable cache.

The read-only cache would typically be mounted on Docker images.

Only infrastructure, no tests yet.

  1. … 77 more files in changeset.
Initial steps towards a 2-stage dependency cache

This commit introduces the infrastructure required to get a 2-stage

dependency cache, consisting of a read-only, shareable cache and

a read-write local mutable cache.

The read-only cache would typically be mounted on Docker images.

Only infrastructure, no tests yet.

  1. … 77 more files in changeset.
Initial steps towards a 2-stage dependency cache

This commit introduces the infrastructure required to get a 2-stage

dependency cache, consisting of a read-only, shareable cache and

a read-write local mutable cache.

The read-only cache would typically be mounted on Docker images.

Only infrastructure, no tests yet.

  1. … 77 more files in changeset.
Initial steps towards a 2-stage dependency cache

This commit introduces the infrastructure required to get a 2-stage

dependency cache, consisting of a read-only, shareable cache and

a read-write local mutable cache.

The read-only cache would typically be mounted on Docker images.

Only infrastructure, no tests yet.

  1. … 77 more files in changeset.
Initial steps towards a 2-stage dependency cache

This commit introduces the infrastructure required to get a 2-stage

dependency cache, consisting of a read-only, shareable cache and

a read-write local mutable cache.

The read-only cache would typically be mounted on Docker images.

Only infrastructure, no tests yet.

  1. … 77 more files in changeset.
Move InetAddressFactory to :base-services and work around JDK bug

See https://bugs.openjdk.java.net/browse/JDK-8143378

  1. … 24 more files in changeset.
Move InetAddressFactory to :base-services and work around JDK bug

See https://bugs.openjdk.java.net/browse/JDK-8143378

  1. … 24 more files in changeset.
Move InetAddressFactory to :base-services and work around JDK bug

See https://bugs.openjdk.java.net/browse/JDK-8143378

  1. … 24 more files in changeset.
Run perf with loopback

  1. … 14 more files in changeset.
Move ClassLoaderHierarchyHasher to :hashing

  1. … 34 more files in changeset.
Move ClassLoaderHierarchyHasher to :hashing

  1. … 34 more files in changeset.
Move Stat and Chmod to :files

  1. … 38 more files in changeset.