On 14/02/2012, at 8:50 PM, Daz DeBoer <[email protected]> wrote:
> On 13 February 2012 23:44, Szczepan Faber <[email protected]> wrote: > Yesterday me & Daz talked a bit about the daemon matching and honoring > gradle.properties settings for the regular gradle. I've slept on it and have > some feedback. Sorry if my email is not verbose enough - I'm cutting the > story short. > > The current approach we aim for is: > > -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. 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. > 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? > It will now be trivial to add support for forking a single-use daemon for any > build: we just need to a) bypass the search for existing daemons and b) > ensure the created process doesn't live beyond our build. I guess --stop isn't a problem because it's not going to change anything. > 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. > because: > > 1. It avoids tricky process matching. Java's getInputArguments() is not > reliable enough for strict matching: extra vm options of some platforms, > rubbish options when some sys. properties are quoted with spaces, and > possibly other problems as they usually come in clusters. > > 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? > It feels like a natural step towards default daemon and (a bit of a song of > future) native client. I.e. moving away from "in-process or daemon" mode > towards "short-lived daemon or long-lived daemon" mode. > > I tend to like this approach. "Matching" the current process with the > requirements is going to be tricky indeed. Ah, now I see… we can match based on what was declared instead of what is. > 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. > A couple of issues: > 1) How do we determine the startup settings for a foreground daemon? We can require them in some fashion I guess. I think we should remove the foreground demon from public view. > 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. > > -- > Darrell (Daz) DeBoer > Principal Engineer, Gradleware > http://www.gradleware.com >
