High-level, it seems like we might want to think about how to tie the lifecycle of the data to the lifecycle of the associated CompilationUnit/CompiledClass. Maybe this should actually be moved into a lazy-initialized transient field in CompiledClass instead of having to use a map.
Also, now that we're going to be caching these in memory, these classes are in sore need of a "remove unused data" pass. Much of the contained data isn't used in practice. http://gwt-code-reviews.appspot.com/1420809/diff/1/dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java File dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java (right): http://gwt-code-reviews.appspot.com/1420809/diff/1/dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java#newcode249 dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java:249: new ReferenceMap(AbstractReferenceMap.HARD, AbstractReferenceMap.SOFT); Needs to be synchronized? http://gwt-code-reviews.appspot.com/1420809/diff/1/dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java#newcode467 dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java:467: Map<String, Object> values = Maps.newHashMap(annotData.getValues()); What's the motivation here? http://gwt-code-reviews.appspot.com/1420809/diff/1/dev/core/src/com/google/gwt/dev/util/ByteArrayWrapper.java File dev/core/src/com/google/gwt/dev/util/ByteArrayWrapper.java (right): http://gwt-code-reviews.appspot.com/1420809/diff/1/dev/core/src/com/google/gwt/dev/util/ByteArrayWrapper.java#newcode36 dev/core/src/com/google/gwt/dev/util/ByteArrayWrapper.java:36: && Arrays.equals(bytes, ((ByteArrayWrapper) obj).bytes); Why not compare hashCode before the expensive byte compare? http://gwt-code-reviews.appspot.com/1420809/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
