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