On Thu, Feb 11, 2010 at 7:43 PM, Scott Blum <[email protected]> wrote:
> I have a few comments, but first I wanted to raise the point that I'm not > sure why we're having this argument about maximally sharded Precompiles at > all. For one thing, it's already implemented, and optional, via > "-XshardPrecompile". I can't think of any reason to muck with this, or why > it would have any relevance to sharded linking. Can we just table that part > for now, or is there something I'm missing? > There are still two modes, but there's no more need for an explicit argument. For Compiler, precompile is never sharded. For the three-stage entry points, full sharding happens iff all linkers are shardable. > - I'm not sure why development mode wouldn't run a sharded link first. > Wouldn't it make sense if development mode works just like production > compile, it just runs a single "development mode" permutation shard link > before running the final link? > Sure, we can do that. Note, though, that they will be running against an empty ArtifactSet, because there aren't any compiles for them to look at. Thus, they won't typically do anything. > 2) Instead of trying to do automatic thinning, we just let the linkers > themselves do the thinning. For example, one of the most > serialization-expensive things we do is serialize/deserialze symbolMaps. To > avoid this, we update SymbolMapsLinker to do most of its work during > sharding, and update IFrameLinker (et al) to remove the CompilationResult > during the sharded link so it never gets sent across to the final link. > In addition to the other issues pointed out, note that this adds ordering constraints among the linkers. Any linker that deletes something must run after every linker that wants to look at it. Your example wouldn't work as is, because it would mean no POST linker can look at CompilationResults. It also wouldn't work to put the deletion in a POST linker, for the same reason. We'd have to work out a way for the deletions to happen last, after all the normal linkage activity. Suppose, continuing that idea, we add a POSTPOST order that is used only for deletion. If it's really only for deletion, then the usual link() API is overly general, because it lets linkers both add and remove artifacts during POSTPOST, which is not desired. So, we want a POSTPOST API that is only for deletion. Linkers somehow or another mark artifacts for deletion, but not anything else. At this point, though, isn't it pretty much the same as the automated thinning in the initial proposal? > The pros to this idea are (I think) that you don't break anyone... instead you > opt-in to the optimization. If you don't do anything, it should still work, but > maybe slower than it could. The proposal that started this thread also does not break anyone. Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
