On Sat, Feb 21, 2009 at 2:47 AM, Scott Blum <sco...@google.com> wrote: > On Fri, Feb 20, 2009 at 3:09 AM, nicolas de loof <nicolas.del...@gmail.com> > wrote: >> >> I may be wrong, but doesn't the ProcessBuilder use the OS interpreter to >> parse the forked process command line & arguments ? (This may be JRE >> dependenant) > > Not sure, but it's worth pointing out that CompilePermsServer doesn't > actually need a really long classpath... it is designed to work with only > gwt-dev on the classpath.
It uses the classpath of the JVM in order to pick up both gwt-dev and any local overrides so that it can be used while operating in an IDE. An externally-configurable override does not exist, but could be added. > Even when you don't get anywhere near the memory ceiling, we've seen that > empirically, GC appears to be super-linear with respect to the amount of > heap being used. By sharding across processes instead of threads, we tend > to find that GC overhead is reduced overall. Overhead is reduced by limiting the number of full collections. It's cheaper to create a new address space and reclaim it when the process terminates than it is to repeatedly scrub. > Bob, I went searching for the design doc for multi-process/threaded compiles > but couldn't find it. Does one exist already? If not, could this email be > a start for one? One does not. I can start one next week when I get back. -- Bob Vawter Google Web Toolkit Team --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---