Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Replace FileMetadata by FileMetadataSnapshot

  1. … 16 more files in changeset.
Introduce access type on FileSystemLocationSnapshot

but don't fill it, yet.

  1. … 23 more files in changeset.
Introduce access type on FileSystemLocationSnapshot

but don't fill it, yet.

  1. … 23 more files in changeset.
Introduce access type on FileSystemLocationSnapshot

but don't fill it, yet.

  1. … 23 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.
Fixes for test coverage.

  1. … 6 more files in changeset.
Add more test coverage for using CopySpec with instant execution.

Reduce the verbosity of some instant execution logging.

  1. … 16 more files in changeset.
Add more test coverage for using CopySpec with instant execution.

Reduce the verbosity of some instant execution logging.

  1. … 16 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. … 404 more files in changeset.
Fix tests

  1. … 369 more files in changeset.
Notify VFS about local state cleanup

#12146

  1. … 3 more files in changeset.
Replace several usages of direct `FileCollection` implementation instantiation with a factory method.

Remove a couple of `FileCollection` implementations, as these can now be replaced with public API factory methods instead.

  1. … 33 more files in changeset.
Replace several usages of direct `FileCollection` implementation instantiation with a factory method.

Remove a couple of `FileCollection` implementations, as these can now be replaced with public API factory methods instead.

  1. … 33 more files in changeset.
Replace several usages of direct `FileCollection` implementation instantiation with a factory method.

Remove a couple of `FileCollection` implementations, as these can now be replaced with public API factory methods instead.

  1. … 33 more files in changeset.
Replace several more usages of direct `FileCollection` implementation instantiation with a factory method.

Remove/deprecate a couple of `FileCollection` implementations, as these can now be replaced with public API factory methods instead.

The deprecation is intended to be tempory, until the play plugin can be updated to use public APIs instead, then the implementation will be removed.

  1. … 44 more files in changeset.
Replace several more usages of direct `FileCollection` implementation instantiation with a factory method.

Remove/deprecate a couple of `FileCollection` implementations, as these can now be replaced with public API factory methods instead.

The deprecation is intended to be tempory, until the play plugin can be updated to use public APIs instead, then the implementation will be removed.

  1. … 44 more files in changeset.
Fix classycle

  1. … 35 more files in changeset.
Move ImplementationSnapshot to :snapshots

  1. … 35 more files in changeset.
Move ImplementationSnapshot to :snapshots

  1. … 35 more files in changeset.
Move BuildCacheCommandFactory to :build-cache

And its implementation to :core (though it should end up in some build-cache-related subproject eventually).

  1. … 16 more files in changeset.
Add FileCollectionFingerprint.getRootPaths()

to simplify the notification of the VFS for changes from a

file collection fingerprint.

  1. … 4 more files in changeset.
Inform VFS for output cleanup in CleanupOutputsStep

The previous outputs can be in a different place for the cleanup, e.g.

when the task is re-configured. Therefore, the VFS needs to be informed

that something will change there.

  1. … 5 more files in changeset.
Inform VFS for output cleanup in CleanupOutputsStep

The previous outputs can be in a different place for the cleanup, e.g.

when the task is re-configured. Therefore, the VFS needs to be informed

that something will change there.

  1. … 5 more files in changeset.
Inform VFS for output cleanup in CleanupOutputsStep

The previous outputs can be in a different place for the cleanup, e.g.

when the task is re-configured. Therefore, the VFS needs to be informed

that something will change there.

  1. … 5 more files in changeset.
Inform VFS for output cleanup in CleanupOutputsStep

The previous outputs can be in a different place for the cleanup, e.g.

when the task is re-configured. Therefore, the VFS needs to be informed

that something will change there.

  1. … 5 more files in changeset.
Rename types for better understanding

We distinguish between complete and incomplete snapshots.

  1. … 67 more files in changeset.