@Bob: I am trying to work though this patch as quickly as I can, but am not
quite done, so I thought I'd send you a few points and questions as I'm
working through it. FWIW, I've confirmed that the -XdisableClassMetadata
works "in the wild" on a couple of real apps, which is great. I'll do the
same for the RPC part of the patch, probably tomorrow morning.
---
One thing this could really use is a simple wiki page describing the basic
approach, the addition of the ::clazz magic identifier, and what changes to
(and requirements on) user code may be necessary (e.g., does using this
strictly require a RPC whitelist implementation?). It would be especially
nice to have this on deck for the 2.0 doc and release notes.
ControlFlowAnalyzer:- Just to make sure I understand this correctly, can you
explain why we had to move the class-literal rescue code to JVariable?
JProgram/CompilingClassLoader:
- It feels like there's got to be some way to merge the implementations of
getTypeFromJsniRef() and getClassFromBinaryName(). Feel free to tell me it's
not worth it, though.
JsInliner:
- (861) Why the comment about clinits being folded into the JsProgram body?
I think I'm missing something here -- are we calling clinits in a context
where they might get inlined directly into the outer scope?
In the jjs tests, is there any eay way to share all those class name tests
(i.e. startsWith("Class$")) without getting into heavy refactoring? It seems
like we're only going to run into this sort of thing more as we start
implementing optional optimizations (e.g. disable cast-checking), and it
would be good to start a sensible pattern for these kinds of tests.
... more to come.
On Thu, Feb 5, 2009 at 12:28 AM, BobV <b...@google.com> wrote:
> I've been working on a branch to eliminate the use of type names by
> GWT RPC. Type names over the wire are replaced with obfuscated
> identifiers and the client-side RPC code no longer relies on
> hard-coded type names. The RPC whitelist file is extended to include
> a map from type names to obfuscated identifiers.
>
> You can either check out the branch or use the following merge command:
> svn merge -r4602:HEAD
>
> http://google-web-toolkit.googlecode.com/svn/changes/bobv/elide_rpc_type_names_r4602
>
> This initial version makes the type removal opt-in because it's
> fundamentally incompatible with the LegacySerializationPolicy. To turn
> it on add the following to your module definition after you inherit
> User.gwt.xml:
>
> <inherits name="com.google.gwt.user.RemoteServiceObfuscateTypeNames" />
>
> Additional savings can be had by hacking our Class.java's getName()
> method to return a constant value. With both of these optimizations,
> a modified Dynatable sample's size was reduced by 8% on average (91k
> -> 83k) by completely eliminating all class names from the compiled
> code. Payload size was reduced by 18% (1735b -> 1421b) due to the use
> of shorter identifiers. I couldn't measure a meaningful speed
> improvement, although I suspect that shorter names would result in
> faster hash lookups.
>
> Future changes:
> - A compiler flag or optional module to neuter Class.getName().
> - The obfuscated string identifiers could be replaced by purely
> numeric values in the wire format. Supporting legacy RPC setups
> (IsSerializable and no RPC whitelist) requires String-based APIs,
> while a numeric system would require int-based APIs. I would suggest
> that we plan to drop support for legacy-style RPC (and force the use
> of the whitelist / meta-data file) in the next major release to
> further streamline the wire format and de-cruft the RPC code.
>
> --
> Bob Vawter
> Google Web Toolkit Team
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
