Well, this is somewhat anti-climatic, but, AFAICT, it was just MemoryUnitCache's maps using soft values.
Instead of turning on TRACE everywhere, I upgraded MinimalRebuildCache's "known modified type" output to WARN. (It would be great to have log4j-style package-level knobs in the GWT log output.) That was always right (only 1 .java file with it's 3 inner types). After trying a few other things, I also upgraded CompilationStateBuilder's doBuildFrom, where it reads from the unit cache, "Used x/y units from cache" line. And that's it; whenever I have a slow load, I'm loading only ~3k out of ~4k units from cache. Or less (I saw zero once, after I had particularly annoyed the GC somehow). Whenever it's fast, all ~4k (minus the newly invalidated one) are loaded from the unit cache. I removed MemoryUnitCache's maps' .softValues() and that seems to fix it. Upping the Xmx from 1g to 2g also fixes it, and provides a nice speed up anyway. Perhaps 1g was a naively low setting, but, AFAICT, without poking in the code (or turning on TRACE and knowing exactly what to look for), there are no visible hints about "hey, the cache isn't keeping up, that's why your reloads are slow, so up your Xmx". Given how important the unit cache is now, perhaps the maps should no longer use soft values? In my case, I would have preferred an OOME as an blatant "needs more RAM" than silent sub-optimal behavior. - Stephen -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/20141020233903.2a9a93d1%40sh9. For more options, visit https://groups.google.com/d/optout.
