http://gwt-code-reviews.appspot.com/1236801/diff/22001/6009 File dev/core/src/com/google/gwt/dev/javac/typemodel/JClassType.java (right):
http://gwt-code-reviews.appspot.com/1236801/diff/22001/6009#newcode574 dev/core/src/com/google/gwt/dev/javac/typemodel/JClassType.java:574: * structure of a type. Use a type's publicly accessible api to build a I see now that I think we are talking about 2 different things. When I said public api, I really meant the public methods available to be called by a generator. So I wasn't referring to things which are public/private/protected in the java type.....So, I see the confusion, and will make note of your original point, that it was confusing to refer to the "type's publicly accessible api"....Yes of course, a generator can inspect private fields/annotations of a type, and JSNI references apparently don't respect a type's public/private accessibility anyway.... http://gwt-code-reviews.appspot.com/1236801/diff/22001/6009#newcode683 dev/core/src/com/google/gwt/dev/javac/typemodel/JClassType.java:683: lazyTypeStructureSignature = Util.computeStrongName(sb.toString().getBytes()); On 2011/01/04 22:56:41, tobyr wrote:
I don't understand how implementation is related to this. Specific
examples are
things like access specifiers and other modifiers. No need to generate
the
string "private static transient volatile" when you can append a
single 16-bit
word that's already been read from the bytecode. JVMS signatures also
tend to be
more compact and are also directly available from the bytecode (no
computation
required).
Yeah, for parts of a type's structure, you could have a simple bit map to represent access specifiers, etc. But you still need to guarantee unique representation for anything that has a name in it, such as the name of a field, method, etc. You need to know if someone changed the name of a method, etc. So, any solution will be dominated by tracking the specific string values within the type structure, I'm not sure much will be saved by creating bitmasks for the parts that don't involve strings. However, I do think we can do more of an on the fly calculation for a hash, rather than copying lots of substrings around. Using the StringBuilder was meant as part of a solution of that, but of course there are too many appends of .toString() methods for it to be optimal. Access to the bytecode isn't really available, is it, by the time we are looking up types in TypeOracle, no?
I would feel best if you can get a measurement, prove it's a net win,
then file
an issue to make sure we take care of it.
I'll work on characterizing the numbers (e.g. compare with a version that uses file time stamps, vs. type signatures, vs. no caching of client bundle at all).... http://gwt-code-reviews.appspot.com/1236801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
