http://gwt-code-reviews.appspot.com/1375802/diff/16004/dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java File dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java (right):
http://gwt-code-reviews.appspot.com/1375802/diff/16004/dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java#newcode91 dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java:91: .synchronizedMap(new ReferenceMap(AbstractReferenceMap.HARD, AbstractReferenceMap.SOFT)); I thought about these maps while exercising this evening. Better blood flow to the head I guess. I remember one of the caveats of WeakHashMap is that if the (weak) key is referenced by the value, the key will never be garbage collected and the entry will always remain in the map. My thought was that the references for unitMap should be SOFT, SOFT, since we want the cache to be garbage collected and the key references a string in the value. Or, should we leave it as HARD, SOFT and do something to make sure we have a copy of the type name value when we add the key to unitMap? For the unitMapByContentId we probably want both the key and value to be WEAK, since they are just an alternate index on unitMap. Would that also eliminate the need to remove the contentId key when we replace a unit in unitMap? http://gwt-code-reviews.appspot.com/1375802/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
