On Wed, Apr 8, 2009 at 11:17 AM, John Tamplin <j...@google.com> wrote: > On Wed, Apr 8, 2009 at 11:00 AM, Lex Spoon <sp...@google.com> wrote: >> >> Scott, when you get back, can you review this tiny patch, or propose a >> different way to solve the problem? >> >> The problem is that when precompiles are sharded, it's not actually >> sound to discard all early compilation state in the middle of >> precompile(). If this is done, then the next precompile shard will >> not have that state available. As a result, sharded precompiles are >> currently broken in trunk. >> >> What the patch does is simply turn on the option to retain compilation >> state whenever sharded precompiles are enabled. That fixes sharded >> precompiles, and is surely safe in general. > > How much data does that wind up keeping around? If much of the data from > the full set of precompiles is kept in RAM, does that invalidate the idea of > sharding precompile at all?
I don't know how much, but does it matter? We can't discard data that the compiler actually still needs. The trunk is currently broken because we do. For the fundamental question, no, it's not much of the data from the full set of precompiles. It's things like deferred binding rules. Lex --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
