ClassLoader behavior of custom classes for repeat builds with daemon

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

ClassLoader behavior of custom classes for repeat builds with daemon

Xavier Ducrohet
Hello,

It seems that subsequent builds done with the daemon are using brand new instances of custom classes instead of reusing the ones loaded on the first build? Is that correct?

I'm trying to dynamically load a jar file only once during the build so that it's reused by all the tasks for all the modules, and it seems that repeat build will trigger a new load. This is a perfect behavior for me since I don't have to deal with unloading it, but I wanted to make sure that this was expected.

thanks!
Xav
Reply | Threaded
Open this post in threaded view
|

Re: ClassLoader behavior of custom classes for repeat builds with daemon

Adam Murdoch

On 17 Jan 2014, at 2:40 pm, Xavier Ducrohet <[hidden email]> wrote:

Hello,

It seems that subsequent builds done with the daemon are using brand new instances of custom classes instead of reusing the ones loaded on the first build? Is that correct?

It’s unspecified at the moment. Right now it happens to recreate the ClassLoaders on each build, but we do plan to change this soon, as having the plugin and build script classes warmed gives a nice improvement to build execution time and allows plugins to do things like in-memory caching. It also slows down permgen leaks too.


I'm trying to dynamically load a jar file only once during the build so that it's reused by all the tasks for all the modules, and it seems that repeat build will trigger a new load.

Why do you need to do this? Are you loading stuff out of the SDK that the task implementations use?

This is a perfect behavior for me since I don't have to deal with unloading it, but I wanted to make sure that this was expected.

It’s the current behaviour, but you shouldn’t count on it.


--
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: ClassLoader behavior of custom classes for repeat builds with daemon

Xavier Ducrohet

On Fri, Jan 17, 2014 at 4:15 PM, Adam Murdoch <[hidden email]> wrote:

On 17 Jan 2014, at 2:40 pm, Xavier Ducrohet <[hidden email]> wrote:

Hello,

It seems that subsequent builds done with the daemon are using brand new instances of custom classes instead of reusing the ones loaded on the first build? Is that correct?

It’s unspecified at the moment. Right now it happens to recreate the ClassLoaders on each build, but we do plan to change this soon, as having the plugin and build script classes warmed gives a nice improvement to build execution time and allows plugins to do things like in-memory caching. It also slows down permgen leaks too.


What happens if I do 2 builds at the same time that use the daemon. Would both build share the same classloaders? This means static class fields would be shared between the 2 builds?
 

I'm trying to dynamically load a jar file only once during the build so that it's reused by all the tasks for all the modules, and it seems that repeat build will trigger a new load.

Why do you need to do this? Are you loading stuff out of the SDK that the task implementations use?


Yes, we have a Java based tool that's used during the build, sometimes many time during the same project builds. I'd like to load it instead of calling it through the shell script which would spawn a new VM for it. The question is when do I unload it. Though I guess it'll get unloaded when the rest of the custom plugin classes gets unloaded, so it's not too much of a problem. I'm not planning to keep too many things around anyway.
 
This is a perfect behavior for me since I don't have to deal with unloading it, but I wanted to make sure that this was expected.

It’s the current behaviour, but you shouldn’t count on it.


--
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: ClassLoader behavior of custom classes for repeat builds with daemon

Adam Murdoch

On 18 Jan 2014, at 2:03 pm, Xavier Ducrohet <[hidden email]> wrote:


On Fri, Jan 17, 2014 at 4:15 PM, Adam Murdoch <[hidden email]> wrote:

On 17 Jan 2014, at 2:40 pm, Xavier Ducrohet <[hidden email]> wrote:

Hello,

It seems that subsequent builds done with the daemon are using brand new instances of custom classes instead of reusing the ones loaded on the first build? Is that correct?

It’s unspecified at the moment. Right now it happens to recreate the ClassLoaders on each build, but we do plan to change this soon, as having the plugin and build script classes warmed gives a nice improvement to build execution time and allows plugins to do things like in-memory caching. It also slows down permgen leaks too.


What happens if I do 2 builds at the same time that use the daemon. Would both build share the same classloaders? This means static class fields would be shared between the 2 builds?

You get a new daemon. Each daemon runs a single build at a time and if there are no idle daemons available the client starts a new one.

 

I'm trying to dynamically load a jar file only once during the build so that it's reused by all the tasks for all the modules, and it seems that repeat build will trigger a new load.

Why do you need to do this? Are you loading stuff out of the SDK that the task implementations use?


Yes, we have a Java based tool that's used during the build, sometimes many time during the same project builds. I'd like to load it instead of calling it through the shell script which would spawn a new VM for it. The question is when do I unload it. Though I guess it'll get unloaded when the rest of the custom plugin classes gets unloaded, so it's not too much of a problem. I'm not planning to keep too many things around anyway.

It’s a pretty common problem for plugin authors where you have some Java tool that needs to be visible to (usually) the task classes but which needs some plugin-specific configuration (say, checkstyle version or sdk install directory or whatever) to be done before exactly what to make visible is known. At some point I’d like to add a general purpose solution to this that plugins authors can use.


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