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
-~----------~----~----~----~------~----~------~--~---

Reply via email to