Memory pressure when testing a custom plugin

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Memory pressure when testing a custom plugin

Xavier Ducrohet
It's become harder to test our plugin due to memory pressure. Before, the daemon would die every now and then but recently it's become the case much more often.

It's at a point where we cannot run our tests unless gradle.properties contains at least
org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=1024m

A lot of our functional tests are basically building a list of test projects. The test implementations use the tooling API to build the projects and inspect the output.

Most of the time the daemon dies in the middle of running the test and we get this output:


Caused by: org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been stopped, killed or may have crashed)

When I looked at the dumped hprof file I really don't see anything interesting. At first I thought that it was because the daemon had loaded a lot of different versions of our plugin, but now it happens with a single run of the tests from a clean slate (no daemon running).

Any idea on how I can figure out what is going? Also is there any related to task and plugin lifecycle that could lead to leaks?
Reply | Threaded
Open this post in threaded view
|

Re: Memory pressure when testing a custom plugin

Adam Murdoch

On 9 Jan 2014, at 1:15 pm, Xavier Ducrohet <[hidden email]> wrote:

It's become harder to test our plugin due to memory pressure. Before, the daemon would die every now and then but recently it's become the case much more often.

It's at a point where we cannot run our tests unless gradle.properties contains at least
org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=1024m

A lot of our functional tests are basically building a list of test projects. The test implementations use the tooling API to build the projects and inspect the output.

Most of the time the daemon dies in the middle of running the test and we get this output:

Caused by: org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been stopped, killed or may have crashed)

When I looked at the dumped hprof file I really don't see anything interesting. At first I thought that it was because the daemon had loaded a lot of different versions of our plugin, but now it happens with a single run of the tests from a clean slate (no daemon running).

Any idea on how I can figure out what is going? Also is there any related to task and plugin lifecycle that could lead to leaks?

Not really to both. Can you get me the hprof file? The daemon log files would be useful too.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

Re: Memory pressure when testing a custom plugin

Xavier Ducrohet

Where can I find the daemon log?

I'll do a run tomorrow and send you the hprof file.

On Jan 8, 2014 11:14 PM, "Adam Murdoch" <[hidden email]> wrote:

On 9 Jan 2014, at 1:15 pm, Xavier Ducrohet <[hidden email]> wrote:

It's become harder to test our plugin due to memory pressure. Before, the daemon would die every now and then but recently it's become the case much more often.

It's at a point where we cannot run our tests unless gradle.properties contains at least
org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=1024m

A lot of our functional tests are basically building a list of test projects. The test implementations use the tooling API to build the projects and inspect the output.

Most of the time the daemon dies in the middle of running the test and we get this output:


Caused by: org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been stopped, killed or may have crashed)

When I looked at the dumped hprof file I really don't see anything interesting. At first I thought that it was because the daemon had loaded a lot of different versions of our plugin, but now it happens with a single run of the tests from a clean slate (no daemon running).

Any idea on how I can figure out what is going? Also is there any related to task and plugin lifecycle that could lead to leaks?

Not really to both. Can you get me the hprof file? The daemon log files would be useful too.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

Re: Memory pressure when testing a custom plugin

Adam Murdoch

On 9 Jan 2014, at 3:32 pm, Xavier Ducrohet <[hidden email]> wrote:

Where can I find the daemon log?


In ~/.gradle/daemon/${gradle-version}/

I'll do a run tomorrow and send you the hprof file.

On Jan 8, 2014 11:14 PM, "Adam Murdoch" <[hidden email]> wrote:

On 9 Jan 2014, at 1:15 pm, Xavier Ducrohet <[hidden email]> wrote:

It's become harder to test our plugin due to memory pressure. Before, the daemon would die every now and then but recently it's become the case much more often.

It's at a point where we cannot run our tests unless gradle.properties contains at least
org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=1024m

A lot of our functional tests are basically building a list of test projects. The test implementations use the tooling API to build the projects and inspect the output.

Most of the time the daemon dies in the middle of running the test and we get this output:

Caused by: org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been stopped, killed or may have crashed)

When I looked at the dumped hprof file I really don't see anything interesting. At first I thought that it was because the daemon had loaded a lot of different versions of our plugin, but now it happens with a single run of the tests from a clean slate (no daemon running).

Any idea on how I can figure out what is going? Also is there any related to task and plugin lifecycle that could lead to leaks?

Not really to both. Can you get me the hprof file? The daemon log files would be useful too.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com





--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

Re: Memory pressure when testing a custom plugin

Xavier Ducrohet
ok, I shared an archive with you through google drive.


On Thu, Jan 9, 2014 at 12:02 AM, Adam Murdoch <[hidden email]> wrote:

On 9 Jan 2014, at 3:32 pm, Xavier Ducrohet <[hidden email]> wrote:

Where can I find the daemon log?


In ~/.gradle/daemon/${gradle-version}/

I'll do a run tomorrow and send you the hprof file.

On Jan 8, 2014 11:14 PM, "Adam Murdoch" <[hidden email]> wrote:

On 9 Jan 2014, at 1:15 pm, Xavier Ducrohet <[hidden email]> wrote:

It's become harder to test our plugin due to memory pressure. Before, the daemon would die every now and then but recently it's become the case much more often.

It's at a point where we cannot run our tests unless gradle.properties contains at least
org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=1024m

A lot of our functional tests are basically building a list of test projects. The test implementations use the tooling API to build the projects and inspect the output.

Most of the time the daemon dies in the middle of running the test and we get this output:


Caused by: org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been stopped, killed or may have crashed)

When I looked at the dumped hprof file I really don't see anything interesting. At first I thought that it was because the daemon had loaded a lot of different versions of our plugin, but now it happens with a single run of the tests from a clean slate (no daemon running).

Any idea on how I can figure out what is going? Also is there any related to task and plugin lifecycle that could lead to leaks?

Not really to both. Can you get me the hprof file? The daemon log files would be useful too.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com





--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com