On 14 February 2012 16:28, Luke Daley <[email protected]> wrote: > On 14/02/2012, at 8:50 PM, Daz DeBoer <[email protected]> > wrote: > > On 13 February 2012 23:44, Szczepan Faber <[email protected]> wrote: > >> >> -When no-daemon build starts, we parse the gradle.properties. If the >> settings match the current process we happily continue. If the settings >> don't match the current process we execute the build in a single-life >> daemon. >> > > One thing that worries me here is that at least right now the daemon > doesn't work for some things, but maybe this will drive us to make them > work. >
But the alternative involves adding a whole new way to start Gradle in a separate process. I started down this path (using the same infrastructure as the compiler daemon) but then we'd need to implement bridging of log messages, classloader construction etc. I think this is a bad idea since we're better off making the daemon work in all cases than supporting another way of running Gradle. > Another (which is not a new problem) is the overhead of two jvms. If > JAVA_OPTS says the min heap is 512mb and gradle.properties wants 513 we are > now wasting a bit. > The only way I can see to avoid this is 1) ignore the declared properties (like we currently do) or 2) introduce some sort of native daemon (bash, c++, ...) > I've got the first bit of this done. Now, when we don't find a matching > daemon process and we create a new one, we _always_ use the created > process. It is no longer possible for another client to grab 'our' daemon > process before us, and there's no chance that 'our' daemon will be excluded > because it doesn't satisfy our requirements. > > When would that second bit happen? > > Also, if we are starting a new daemon but it doesn't match the client > environment aren't we in a bad situation? > The issue is that our matching is currently way too specific. The IBM jdk adds all sorts of arguments that are different per invocation, so we had to explicitly ignore these. If we change to match against the 'startup' parameters of the daemon rather than the 'runtime' parameters of the daemon, this should never happen. The alternative is a false negative, which means that we can never find a matching daemon. > I'm leaning towards a simpler approach, e.g. always spawn a child process > when gradle.properties contains process-sensitive settings > > > I'm worried about the overhead of this, but maybe we can negate it over > time by making the first JVM thin and maybe native. > What's the alternative? If we can accurately match the client jvm against the required parameters, then cool. Or have the bash script somehow provide the startup parameters to the process on startup. >> 2. The reason someone configures java settings in gradle.properties is >> because he wants something different than the default. So, in majority of >> cases the client process will not match the 'desired' criteria and we will >> spawn the child process, anyway. So, why do we want to complicate the >> algorithm for a quite unusual use case? Also the more process and java >> configurability we introduce to the gradle.properties, the less likely it >> will be that the client process matches the desired context. >> > > If I read this right, it seems like a build that requires lots of memory > will never reap the benefits of the daemon because we'll start a new one > each time because we don't know if they'll match. Or have I misunderstood? > Szczepan is talking about the non-daemon case. There is little chance that the bash script will have supplied the correct parameters to avoid the need to fork a new jvm. With the daemon it's different, since running the same build again means that the previous daemon instance should match. > I also like the idea of changing the 'daemon matching' so that we don't > compare _everything_ about the daemon process, but only those things that > we explicitly specified at startup. So rather than rely on the daemon to > calculate it's settings, we'd explicitly specify them when creating the > daemon (so I guess we'd create a daemon with certain args, then tell the > daemon "by the way, this is how you were started"). We could then look for > a daemon that was started in the same way we need one started, rather than > looking for a daemon who is running the way we want one running. > > > This is effectively how it works now. > Not really - a daemon process isn't told how it was started, it attempts to determine all of the startup arguments with the MXBean. The client then compares this with the declared requirements to see if the daemon can be used. I'm suggesting we skip the determination step, and just tell the daemon how it was started. 2) If we want to match the regular gradle process to avoid forking, how do > we determine the startup settings of the gradle process? > > > I'd be inclined to say that we handle heap, permgen, maybe encoding and > anything else we give up and fork as Szczepan says. If that's the scope > then we'll be able to get that info via jmx. > Yep this would work. We could match on a limited subset of parameters, and fork in other cases. Could do the same thing for foreground daemon. -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com
