Author: [email protected]
Date: Wed Apr 15 13:36:46 2009
New Revision: 5240
Added:
wiki/EnumOptimizations.wiki
Log:
Created wiki page through web user interface.
Added: wiki/EnumOptimizations.wiki
==============================================================================
--- (empty file)
+++ wiki/EnumOptimizations.wiki Wed Apr 15 13:36:46 2009
@@ -0,0 +1,96 @@
+#summary Optimizations for generated enum code
+
+= Introduction =
+
+Java's enum semantics require each value to essentially be an anonymous
subclass of its enum class. The following example:
+
+{{{
+ enum Foo {
+ FOO_0("0"), FOO_1("1") {
+ public String getMessage() {
+ return "something different";
+ }
+ }, FOO_2("2");
+
+ private final String msg;
+
+ Foo(String msg) {
+ this.msg = msg;
+ }
+
+ public String getMessage() {
+ return msg;
+ }
+ }
+}}}
+
+gives some idea of why it's done this way. The GWT compiler currently
generates the code for enums following these semantics quite literally,
which can lead to some fairly significant bloat. In this case, the
initialization for the Foo enum values alone looks like this:
+
+{{{
+ FOO_0 = $Hello$Foo(new Hello$Foo(), 'FOO_0', 0, '0');
+ FOO_1 = $Hello$Foo$1(new Hello$Foo$1(), 'FOO_1', 1, '1');
+ FOO_2 = $Hello$Foo(new Hello$Foo(), 'FOO_2', 2, '2');
+}}}
+
+along with a class definition for Foo like this:
+
+{{{
+function $Hello$Foo(this$static, enum$name, enum$ordinal, msg){
+ $clinit_6();
+ this$static.ordinal = enum$ordinal;
+ this$static.msg = msg;
+ return this$static;
+}
+
+function getMessage_0(){
+ return this.msg;
+}
+
+function Hello$Foo(){
+}
+
+_ = Hello$Foo.prototype = new Enum();
+_.getMessage = getMessage_0;
+_.typeId$ = 0;
+_.msg = null;
+}}}
+
+and a class definition for Foo$1 like this:
+
+{{{
+function $Hello$Foo$1(this$static, enum$name, enum$ordinal, $anonymous0){
+ $clinit_5();
+ this$static.ordinal = enum$ordinal;
+ this$static.msg = $anonymous0;
+ return this$static;
+}
+
+function getMessage(){
+ return 'something different';
+}
+
+function Hello$Foo$1(){
+}
+
+_ = Hello$Foo$1.prototype = new Hello$Foo();
+_.getMessage = getMessage;
+_.typeId$ = 0;
+}}}
+
+= Improvements =
+
+Clearly it's a lot smaller when obfuscated, but there's plenty of room for
improvement here. It's probably true that most enums, most of the time, are
semantically equivalent to their ordinals (i.e., they just add a bit of
type safety on top of using integers). Also, it's not possible to extend
enums, so the number of cases where the generated code has to deal with
virtual dispatch is somewhat limited.
+
+Giant TODO: How can we make all this stuff simpler and not break the
general case? Ideally, we would compile all enums down to just integers,
but virtual dispatch would seem to make this somewhat complicated.
+
+= Open Questions and Ideas =
+
+ * Does the Java spec say anything about how enums' default toString()
has to behave?
+ * If not, we could probably drop all the strings in enum initializers.
+ * If so, we could probably still drop them, using something like
-XdisableClassMetadata.
+ * Could we deal with virtual dispatch on enum methods by simply
implementing an ordinal-indexed array of function pointers?
+
+
+= Performance Impact =
+
+Any optimizations that make generated enum code smaller seem likely to be
a net performance win, but we'll have to keep a close eye on them to be
sure.
\ No newline at end of file
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
