Thanks, Nicolas, good idea.

On Tue, Feb 24, 2009 at 9:01 AM, nicolas de loof
<[email protected]>wrote:

> I just made a tiny change to the plugin so that the bootclasspath includes
> gwt-dev JAR. This fixes my ClassNotFound issue. I now have many other
> compilation failures with my test project but this may relate to API
> changes.
> Cheers,
> Nicolas
>
>
> On Fri, Feb 20, 2009 at 4:47 PM, Scott Blum <[email protected]> wrote:
>
>> On Fri, Feb 20, 2009 at 3:09 AM, nicolas de loof <
>> [email protected]> 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.
>>
>>
>>> For my personnal info, why do you fork a JVM and not just use multiple
>>> threads using java.util.concurrent  ?
>>>
>>
>> You can manually raise the number of local threads by setting the System
>> property "gwt.jjs.maxThreads".  If you don't set it, it defaults to 1.  The
>> reason we prefer processes to threads has to do with heap usage.  The
>> compiler is extremely memory intensive-- the amount of memory required to
>> compile is nearly linear with the number of permutations you run at the same
>> time.  This causes several problems.
>>
>>    - The user has to start up the VM with a much higher memory ceiling or
>>    they risk running out of memory.
>>    - If you get anywhere near the hard memory ceiling, you'll start
>>    thrashing GC badly and everything will grind to a standstill.  This is far
>>    less likely to happen with multiple processes each with their own heap.
>>    - 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.
>>    - Finally, some operating systems (particularly Linux) will simply
>>    devote more processing time to a set of processes than it will to a single
>>    process with a lot of threads.  We tend to get much higher CPU utilization
>>    with multi-process
>>
>> 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?
>>
>> Thanks,
>> Scott
>>
>>
>>
>>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---

Reply via email to