Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Remove metaspace limits for now

We used to test Gradle with a permgen limit of 320Mb.

However, trying to enforce the same limit for metaspace

on Java8+ consistently leads to OutOfMemoryErrors.

Even raising it significantly to 1G does not seem to solve

all these issues. The only explanation I currently have is

that we introduced a leak between now and the point when we

stopped testing for Java 7.

    • -1
    • +1
Lower memory for the client in our wrapper script

Limit metaspace in our own build

Update memory limit documentation

Mention memory default changes in release notes

    • -0
    • +12
Adjust memory settings in our integration tests

Limit memory for worker processes by default

Our workers for compilation, testing etc. had no default

memory settings until now, which mean that we would use

the default given by the JVM, which is 1/4th of system memory

in most cases. This is way too much when running with a high

number of workers. Limiting this to 256m should be enough for

small to medium sized projects. Larger projects will have to

tweak this value.

Lower memory for the Gradle daemon by default

We have made lots of memory usage improvements to Gradle,

so 512m will be enough for small-medium sized projects.

The assumption here is that power users with large projects

are much more likely to tweak these settings than peole just

getting started.

Also this change limits the metaspace on Java8+, so that memory

leaks in plugins don't go unnoticed.

Lower default memory for the client VM

This VM is only there to display some log messages

by default and thus shouldn't need a lot of memory.

There is the corner case of running the build directly

inside the client VM with --no-daemon. In that case some

users may have to adjust their GRADLE_OPTS environment

variable to accomodate their project.

Expand build scan performance tests again

Merge pull request #7068 from gradle/marc/java11

Fixes for Java 11

Undeprecate --no-rebuild

A change in `buildSrc` causes the whole project to become out-of-date.

Thus, when making small incremental changes, the `--no-rebuild`

command-line option is often helpful to get faster feedback and is

therefore no longer deprecated.

Resolves #6968.

    • -0
    • +5
Fix java opts

Fix typo & slightly adjust format

Fix project template name

Inline the templates script and make the test depend on generating the template

Make the build scan plugin perf test project smaller, but run more iterations

This should hopefully help produce more stable results

Merge pull request #7321 from rjbell4/master

Correct release notes typo

Update wrapper to latest nightly

Signed-off-by: Paul Merlin <>

    • -1
    • +1
Order the scenarios so that the new report understands the baseline correctly

Rebaseline performance tests

We introduced a ThreadLocal in the project locking which slowed things

down a little bit (10s of ms) in several builds. Rebaselining to prevent

this from affecting all branches.

  1. … 17 more files in changeset.
Merge pull request #7229 from gradle/wolfs/de-incubate/pre-2x

De-incubate all APIs pre Gradle 3.0

Merge pull request #7300 from gradle/sg/model/operations

Add model builder build operations

Incubate ComponentReport

That is a software model report.

Incubate JUnitTestSuitePlugin

That is a software model plugin.

Address review feedback

Use the project lock when resolving project dependencies in idea

Correct release notes typo

Signed-off-by: Bob Bell <>

    • -1
    • +1
Merge branch 'release'

Rebaseline 'get IDE model on largeJavaMultiProject for IDEA'