[gwt-contrib] gwt incubator logging with gwt from trunk doesn't compile anymore.
Using the logging module with a gwt build from trunk (since the last week) I get the following error during the gwt compile: ... [java] Loading inherited module 'com.google.gwt.gen2.logging.Logging' [java] Loading inherited module 'com.google.gwt.gen2.logging.CoreLogging' [java] Loading inherited module 'com.google.gwt.event.EventBase' [java][ERROR] Unable to find 'com/google/gwt/ event/EventBase.gwt.xml' on your classpath; could be a typo, or maybe you forgot to include a classpath entry for source? [java] [ERROR] Line 4: Unexpected exception while processing element 'inherits' [java] com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries) ... I checked the gwt-user.jar and there is no EventBase.gwt.xml file anymore, so I guess the package was moved somewhere. Also I tried to compile the incubator project from svn, but currently I get some compile errors, too. Does anybody know what I need to change, that I get this running again? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Optimizing away the builder pattern
Hi gwtc,
I was playing with using super-source to emulate some existing code
that uses a builder pattern and make it efficient in GWT as a
JavaScriptObject. I was hoping that the I could make the Builder just
compile away, but that doesn't seem to be happening. I started
debugging in JsInliner but started to get a bit lost. This is using
svn r5557 on trunk FYI (very recent).
What I am seeing is that if you use a chaining call pattern, the
inliner doesn't realize some of the optimization it can do.
Example usage code:
void example() {
MyData myData = MyData.Builder.create()
.setBar(a)
.setFoo(b).build();
Window.alert(myData.getBar());
Window.alert(myData.getFoo());
}
Output I get (extraneous bits removed, PRETTY mode):
function init(){
var myData;
myData = $setFoo($setBar(new Object(), 'a'), 'b');
$wnd.alert(myData.bar);
$wnd.alert(myData.foo);
}
function $setBar(this$static, s){
this$static.bar = s;
return this$static;
}
function $setFoo(this$static, s){
this$static.foo = s;
return this$static;
}
However, with this similar code:
void example2() {
MyData.Builder builder = MyData.Builder.create();
builder.setBar(a);
builder.setFoo(b);
MyData myData = builder.build();
Window.alert(myData.getBar());
Window.alert(myData.getFoo());
}
The code compiles better (no setters):
builder = new Object();
builder.bar = 'a';
builder.foo = 'b';
myData = builder;
$wnd.alert(myData.bar);
$wnd.alert(myData.foo);
The biggest issue seemed to be that the inliner didn't introduce a
local variable for new Object(), and because of that, it correctly
concluded it couldn't keep copying that expression around. (I traced
through it having issues due to new having side effects.) Even if I
manually create a variable for the Builder at the outset, it still
doesn't help. (FYI, I am using new Object() instead of {} to work
around http://code.google.com/p/google-web-toolkit/issues/detail?id=3568)
I was going to try to dig some more in to the inliner, but any ideas
how to improve this?
Will a later pass remove useless variable aliasing? (Seems like not
from my other example?) If so, I was thinking it might work to have
the inliner introduce a local all the time when it is trying to inline
a non-void function. Smarter methods are of course possible, but I
thought that might be worth a shot.
Any other ideas welcome. MyData class attached below. I tried a
variety of small tweaks to the MyData class and nothing made a
difference.
FYI, my eventual goal is:
var myData = {bar:'a',foo:'b'};
But that seems like an orthogonal optimization (and perhaps
generically useful).
Thanks for your interest, if you read this far,
-brian
PS: I am open to any changes to the MyData code below that a) preserve
the JSO-ness and b) leave the external API the same.
public static interface MyData {
String getFoo();
String getBar();
public static final class Builder extends JavaScriptObject
implements MyData {
protected Builder() {}
public static native Builder create() /*-{
return new Object();
}-*/;
public native String getFoo() /*-{
return this.foo;
}-*/;
public native String getBar() /*-{
return this.bar;
}-*/;
public Builder setFoo(String s) {
setFooImpl(s);
return this;
}
private native void setFooImpl(String s) /*-{
this.foo = s;
}-*/;
public Builder setBar(String s) {
setBarImpl(s);
return this;
}
private native void setBarImpl(String s) /*-{
this.bar = s;
}-*/;
public MyData build() {
return this;
}
}
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Extracting library and ITM
Dear contributors, We would like to interest you in a new extracting feature to GWT. We add a sample application which using this feature and a short documentation (E1.rar and Extracting library and ITM.txt) . We would be happy to hear your comments. Thanks, Elad and Osnat. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r5537 - Ant rework for speed:
On Tue, Jun 16, 2009 at 12:46 AM, Freeland Abbottfabb...@google.com wrote: Ping. Bob, I think you had special interest in this one. ;-) ant clear dist-dev cd user ant test does the right thing. LGTM. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] inliner handles implicit long cast at method return
Reviewers: scottb,
Description:
Issue 3710 is caused by the Java inliner failing to take into account an
implicit cast to long in Integer::longValue(). The inliner already adds
explicit casts to the parameters of inlined methods. This patch has it
do so for return values as well.
If we run into many such problems, we could eliminate the whole class of
them by running the cast normalizer before optimization, thus making all
the casts explicit and impossible to forget.
Please review this at http://gwt-code-reviews.appspot.com/39805
Affected files:
dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
user/test/com/google/gwt/dev/jjs/test/NativeLongTest.java
Index: user/test/com/google/gwt/dev/jjs/test/NativeLongTest.java
===
--- user/test/com/google/gwt/dev/jjs/test/NativeLongTest.java (revision
5562)
+++ user/test/com/google/gwt/dev/jjs/test/NativeLongTest.java (working copy)
@@ -23,6 +23,21 @@
* LongLibTest.
*/
public class NativeLongTest extends GWTTestCase {
+ /**
+ * A class that wraps an int. See {...@link
NativeLongTest#testImplicitCastToLong()}.
+ */
+ private static class IntegerWrapper {
+private final int i;
+
+public IntegerWrapper(int i) {
+ this.i = i;
+}
+
+public long longValue() {
+ return i; // implicit cast to long
+}
+ }
+
private static class RequestIdFactory {
static RequestIdFactory instance = new RequestIdFactory();
@@ -122,6 +137,10 @@
l += 5;
assertEquals(15, l);
assertTrue(15 == l);
+
+// Issue 3710
+IntegerWrapper wrap = new IntegerWrapper(20);
+assertEquals(400L, wrap.longValue() * wrap.longValue());
}
public void testInlinedIntInitializer() {
Index: dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
===
--- dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java (revision
5562)
+++ dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java (working
copy)
@@ -32,6 +32,7 @@
import com.google.gwt.dev.jjs.ast.JReturnStatement;
import com.google.gwt.dev.jjs.ast.JStatement;
import com.google.gwt.dev.jjs.ast.JThisRef;
+import com.google.gwt.dev.jjs.ast.JType;
import com.google.gwt.dev.jjs.ast.JVisitor;
import com.google.gwt.dev.jjs.ast.js.JMultiExpression;
@@ -221,6 +222,7 @@
if (expr != null) {
if (!ignoringReturnValue || expr.hasSideEffects()) {
JExpression clone = cloner.cloneExpression(expr);
+ clone = maybeCast(clone, body.getMethod().getType());
multi.exprs.add(clone);
}
}
@@ -451,13 +453,7 @@
JExpression arg = methodCall.getArgs().get(paramIndex);
JExpression clone = cloner.cloneExpression(arg);
- /*
- * Insert an implicit cast if the types differ; it might get
optimized out
- * later, but in some cases it will force correct math evaluation.
- */
- if (clone.getType() != x.getType()) {
-clone = new JCastOperation(clone.getSourceInfo(), x.getType(),
clone);
- }
+ clone = maybeCast(clone, x.getType());
ctx.replaceMe(clone);
}
}
@@ -493,6 +489,17 @@
return new MethodInliner(program).execImpl();
}
+ /**
+ * Insert an implicit cast if the types differ; it might get optimized
out
+ * later, but in some cases it will force correct math evaluation.
+ */
+ private static JExpression maybeCast(JExpression exp, JType targetType) {
+if (exp.getType() != targetType) {
+ exp = new JCastOperation(exp.getSourceInfo(), targetType, exp);
+}
+return exp;
+ }
+
private JMethod currentMethod;
private final JProgram program;
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT
wave id on the sandbox: eighty
On Mon, Jun 15, 2009 at 7:09 PM, Matt Mastraccimatt...@mastracci.com wrote:
I do as well - I'm mmastrac.
On 15-Jun-09, at 8:02 PM, Ray Cromwell wrote:
I do, cromwellian is my id on the sandbox.
-Ray
On Mon, Jun 15, 2009 at 6:14 PM, Bruce Johnsonbr...@google.com
wrote:
I'm starting to make a bit o' progress on this. I'll send out a
design doc
real soon now.
BTW, anyone on the Contributors list here have Wave sandbox
accounts? Sure
would be easier to discuss this in a wave...
On Mon, Jun 15, 2009 at 7:54 PM, Stefan Haustein
haust...@google.com
wrote:
Ray,
I think we can improve the class over time -- any reasonable
starting
point (even without iterators or with non-optimal iterators) would
help
significantly.
Stefan
On Sat, Jun 13, 2009 at 4:21 AM, Ray Cromwell
cromwell...@gmail.com
wrote:
BTW, the last proposal is very unsafe with some form of escape
analysis since it is unsafe to pass references to classes which
reference local scope to other scopes. Another possibility is a
form
of 'destructuring' of Iterator classes by inlining them completely
into local scope vs escape analysis and then forgoing separate
construction.
A simpler way to maintain for-each with JRE collections without
creating objects is to change the way that for-each deals with
IterableT when T is a List.
The compiler could change:
for(T x : foo) { ... }
where foo is a ListT
into
for(int i=0; ifoo.size(); ++i) {
T x = foo.get(i);
}
instead of calling foo.iterator() and using Iterator methods.
-Ray
On Fri, Jun 12, 2009 at 7:31 PM, Ray
Cromwellcromwell...@gmail.com
wrote:
I'm in the process of some final tweaks on GQuery, so I'll look
at how
much of my private JSArray class I can move over as a patch.
One possibility for avoiding Iterator object creation without
using
flyweights is to introduce a new Iterator type which contains
methods
which are parameterized by the collection and which use my
Extension
Method/Category method JSO trick.
public class FastIteratorT extends JavaScriptObject {
protected FastIterator() {}
public S, T extends ListS FastIteratorS make(TS list) {
return (FastIteratorS)(GWT.isScript() ? makeWeb() :
makeHosted());
}
private final native FastIterator makeWeb() /*-{
return 0;
}-*/;
private final native FastIterator makeHosted() /*-{
return [0];
}-*/;
public final int value() {
return GWT.isScript() ? valueWeb() : valueHosted();
}
public native int valueWeb() /*-{
return this;
}-*/;
public native int valueHosted() /*-{
return this[0];
}-*/;
public native hasNext(ListT list) {
return value() list.size();
}
public native T next(ListT list) {
return list.get(value()++); // unsure if using value() as
rvalue
will work here
}
}
then you should be able to write code like
ListString foo = getList();
FastIteratorString iter = FastIterator.make(foo);
while(iter.hasNext(foo)) {
String s = iter.next(foo);
}
Why doesn't this create any additional objects? Because
'iter'/FastIterator is actually a native JS number/scalar type,
and
what this is really doing is simulating the addition of
hasNext()/next() to the number's prototype.
We could dispense with the need for an additional parameter if
GWT had
a magic method for allocating new local variables/symbols in the
local
scope. Imagine if writing
VariableT x = GWT.createVariable(0);
was a magic method that just generated a 'var x = 0'
declaration, only
it promised to always be inlined and do so in the caller's scope.
'Variable' would be a magic class that never creates fields on the
actual object themselves and are pruned/removed at runtime.
Then you could have FastIterator impersonate a reference to the
underlying ListT, and rewrite hasNext()/next() as:
VariableInt x = GWT.createVariableInt(0);
public boolean hasNext() {
return x.get() this.size();
}
public T next() {
return this.get(x.get()++); // or x.postIncrement()
}
this would produce code that would create no additional objects as
well as maintain Iterator-like interface.
-Ray
On Thu, Jun 11, 2009 at 7:25 AM, Stefan Hausteinhaust...@google.com
wrote:
+1 Ray
Could you contribute your implementation(s)?
On Thu, Jun 11, 2009 at 12:51 PM, Joel Webber j...@google.com
wrote:
+1 Ray. Now here's the really tricky question. Is there any
way we
can
take advantage of Javascript's for (x in y) { ... } syntax
(and
should we,
given its spotty performance)? My intuition tells me that the
only
way we
could use it would be through a callback, because there's
nothing
like .NET
generators/yield in Javascript.
On Wed, Jun 10, 2009 at 7:26 PM, Ray Cromwell cromwell...@gmail.com
wrote:
My take on this is that there is many places where I'd like
to avoid
JRE collections, but the basic JsArray is too much of a
downgrade. I
don't mind changing it
[gwt-contrib] Re: Optimizing away the builder pattern
I was talking to Scott about the same optimization, recognizing chains of
methods returning this and inlining them as a block. I haven't looked into
what's involved, though, and promise not to until Thursday at least
On Mon, Jun 15, 2009 at 9:11 PM, Brian Stoler bsto...@google.com wrote:
Hi gwtc,
I was playing with using super-source to emulate some existing code
that uses a builder pattern and make it efficient in GWT as a
JavaScriptObject. I was hoping that the I could make the Builder just
compile away, but that doesn't seem to be happening. I started
debugging in JsInliner but started to get a bit lost. This is using
svn r5557 on trunk FYI (very recent).
What I am seeing is that if you use a chaining call pattern, the
inliner doesn't realize some of the optimization it can do.
Example usage code:
void example() {
MyData myData = MyData.Builder.create()
.setBar(a)
.setFoo(b).build();
Window.alert(myData.getBar());
Window.alert(myData.getFoo());
}
Output I get (extraneous bits removed, PRETTY mode):
function init(){
var myData;
myData = $setFoo($setBar(new Object(), 'a'), 'b');
$wnd.alert(myData.bar);
$wnd.alert(myData.foo);
}
function $setBar(this$static, s){
this$static.bar = s;
return this$static;
}
function $setFoo(this$static, s){
this$static.foo = s;
return this$static;
}
However, with this similar code:
void example2() {
MyData.Builder builder = MyData.Builder.create();
builder.setBar(a);
builder.setFoo(b);
MyData myData = builder.build();
Window.alert(myData.getBar());
Window.alert(myData.getFoo());
}
The code compiles better (no setters):
builder = new Object();
builder.bar = 'a';
builder.foo = 'b';
myData = builder;
$wnd.alert(myData.bar);
$wnd.alert(myData.foo);
The biggest issue seemed to be that the inliner didn't introduce a
local variable for new Object(), and because of that, it correctly
concluded it couldn't keep copying that expression around. (I traced
through it having issues due to new having side effects.) Even if I
manually create a variable for the Builder at the outset, it still
doesn't help. (FYI, I am using new Object() instead of {} to work
around http://code.google.com/p/google-web-toolkit/issues/detail?id=3568)
I was going to try to dig some more in to the inliner, but any ideas
how to improve this?
Will a later pass remove useless variable aliasing? (Seems like not
from my other example?) If so, I was thinking it might work to have
the inliner introduce a local all the time when it is trying to inline
a non-void function. Smarter methods are of course possible, but I
thought that might be worth a shot.
Any other ideas welcome. MyData class attached below. I tried a
variety of small tweaks to the MyData class and nothing made a
difference.
FYI, my eventual goal is:
var myData = {bar:'a',foo:'b'};
But that seems like an orthogonal optimization (and perhaps
generically useful).
Thanks for your interest, if you read this far,
-brian
PS: I am open to any changes to the MyData code below that a) preserve
the JSO-ness and b) leave the external API the same.
public static interface MyData {
String getFoo();
String getBar();
public static final class Builder extends JavaScriptObject
implements MyData {
protected Builder() {}
public static native Builder create() /*-{
return new Object();
}-*/;
public native String getFoo() /*-{
return this.foo;
}-*/;
public native String getBar() /*-{
return this.bar;
}-*/;
public Builder setFoo(String s) {
setFooImpl(s);
return this;
}
private native void setFooImpl(String s) /*-{
this.foo = s;
}-*/;
public Builder setBar(String s) {
setBarImpl(s);
return this;
}
private native void setBarImpl(String s) /*-{
this.bar = s;
}-*/;
public MyData build() {
return this;
}
}
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5563 - Ant fixes for platform independence, for dist-dev not needing tools, and
Author: fabb...@google.com
Date: Tue Jun 16 08:28:58 2009
New Revision: 5563
Modified:
trunk/build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/LatestTimeJar.java
trunk/build.xml
trunk/samples/common.ant.xml
trunk/tools/api-checker/build.xml
trunk/tools/soyc-vis/build.xml
Log:
Ant fixes for platform independence, for dist-dev not needing tools, and
for FD release in LatestTimeJar.
Review by: bobv
Modified:
trunk/build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/LatestTimeJar.java
==
---
trunk/build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/LatestTimeJar.java
(original)
+++
trunk/build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/LatestTimeJar.java
Tue Jun 16 08:28:58 2009
@@ -116,8 +116,12 @@
@Override
public void addToZip(ZipOutputStream out, String path) throws
IOException {
FileInputStream inStream = new FileInputStream(tmpFile);
- doZipFile(inStream, out, path, timestamp, archive, mode);
- tmpFile.delete();
+ try {
+doZipFile(inStream, out, path, timestamp, archive, mode);
+tmpFile.delete();
+ } finally {
+inStream.close();
+ }
}
}
Modified: trunk/build.xml
==
--- trunk/build.xml (original)
+++ trunk/build.xml Tue Jun 16 08:28:58 2009
@@ -35,7 +35,7 @@
gwt.ant dir=distro-source target=${build.host.platform} /
/target
- target name=dist-dev depends=buildonly, tools description=Make
this platform's distribution, minus doc and samples
+ target name=dist-dev depends=buildonly description=Make this
platform's distribution, minus doc and samples
gwt.ant dir=distro-source target=${build.host.platform} /
/target
@@ -93,7 +93,7 @@
call-subproject subproject=samples subtarget=checkstyle /
/target
- target name=test depends=dist-one description=Runs all the GWT
tests
+ target name=test depends=dist-dev description=Runs all the GWT
tests
call-subproject subproject=buildtools subtarget=test /
call-subproject subproject=dev subtarget=test /
call-subproject subproject=user subtarget=test /
Modified: trunk/samples/common.ant.xml
==
--- trunk/samples/common.ant.xml(original)
+++ trunk/samples/common.ant.xmlTue Jun 16 08:28:58 2009
@@ -16,7 +16,7 @@
property.ensure name=gwt.user.jar
location=${gwt.build.lib}/gwt-user.jar /
!-- Platform shouldn't matter here, just picking one --
- property.ensure name=gwt.dev.jar
location=${gwt.build.lib}/gwt-dev-linux.jar /
+ property.ensure name=gwt.dev.jar
location=${gwt.build.lib}/gwt-dev-${build.host.platform}.jar /
!-- Mirror directory for scripts; makes building distro easier --
property name=samples.scripts
value=${gwt.build.out}/samples-scripts /
Modified: trunk/tools/api-checker/build.xml
==
--- trunk/tools/api-checker/build.xml (original)
+++ trunk/tools/api-checker/build.xml Tue Jun 16 08:28:58 2009
@@ -7,7 +7,7 @@
property name=tools.build
value=${gwt.build.out}/${project.tail} /
!-- Platform shouldn't matter here, just picking one --
- property.ensure name=gwt.dev.jar
location=${gwt.build.lib}/gwt-dev-linux.jar /
+ property.ensure name=gwt.dev.jar
location=${gwt.build.lib}/gwt-dev-${build.host.platform}.jar /
property.ensure name=gwt.user.jar
location=${gwt.build.lib}/gwt-user.jar /
target name=compile description=Compile all class files
Modified: trunk/tools/soyc-vis/build.xml
==
--- trunk/tools/soyc-vis/build.xml (original)
+++ trunk/tools/soyc-vis/build.xml Tue Jun 16 08:28:58 2009
@@ -7,7 +7,7 @@
import file=${gwt.root}/common.ant.xml /
!-- Platform shouldn't matter here, just picking one --
- property.ensure name=gwt.dev.jar
location=${gwt.build.lib}/gwt-dev-linux.jar /
+ property.ensure name=gwt.dev.jar
location=${gwt.build.lib}/gwt-dev-${build.host.platform}.jar /
target name=clean
delete dir=build/
@@ -41,4 +41,4 @@
target name=checkstyle/
-/project
\ No newline at end of file
+/project
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Optimizing away the builder pattern
As I said, I hadn't looked at all into how feasible this was... but I was
hoping to do it by jiggering the Java AST, really, and not the JS one. That
is, I was looking to rewrite the Java from a chained
builder.setA().setB().setC() to multi-statement
builder.setA();builder.setB();builder.setC(), effectively unwinding any call
on the return value of a method returning this as a special-case pattern,
and let the Java-to-JavaScript compiler run from that.
On Tue, Jun 16, 2009 at 11:59 AM, Ray Cromwell cromwell...@gmail.comwrote:
Even before the inliner gets it, a JSO chained expression like
a().b().c() is going to look like c(b(a())) so the inliner can only
inline the first call.
Automatically introducing temporaries would seem a lot harder. You'd
have to teach the compiler that 'this' is effectively final, and
therefore any method returning this, effectively always returns the
same value, regardless of side effects. Then, you'd have to introduce
the idea that the compiler can introduce temporaries (speculatively),
and later use common subexpression elimination to detect multiple
identical ones and hoist them out.
e.g.
c(b(a()))
becomes
var t1, t2, t3;
t1 = c(t2 = b(t3 = a()))
then, recognizing the that t1=t2=t3=builder=a() with copy propagation
t1 = builder
a(t1)
b(t1)
c(t1)
and now they can be inlined.
This just seems hard to me, since introducing temporaries is
speculative and you'd have introduce another pass to remove them in
the cases where they provided no benefit. However, this could end up
leading to infinite loops if you're not careful.
-Ray
On Mon, Jun 15, 2009 at 6:11 PM, Brian Stolerbsto...@google.com wrote:
Hi gwtc,
I was playing with using super-source to emulate some existing code
that uses a builder pattern and make it efficient in GWT as a
JavaScriptObject. I was hoping that the I could make the Builder just
compile away, but that doesn't seem to be happening. I started
debugging in JsInliner but started to get a bit lost. This is using
svn r5557 on trunk FYI (very recent).
What I am seeing is that if you use a chaining call pattern, the
inliner doesn't realize some of the optimization it can do.
Example usage code:
void example() {
MyData myData = MyData.Builder.create()
.setBar(a)
.setFoo(b).build();
Window.alert(myData.getBar());
Window.alert(myData.getFoo());
}
Output I get (extraneous bits removed, PRETTY mode):
function init(){
var myData;
myData = $setFoo($setBar(new Object(), 'a'), 'b');
$wnd.alert(myData.bar);
$wnd.alert(myData.foo);
}
function $setBar(this$static, s){
this$static.bar = s;
return this$static;
}
function $setFoo(this$static, s){
this$static.foo = s;
return this$static;
}
However, with this similar code:
void example2() {
MyData.Builder builder = MyData.Builder.create();
builder.setBar(a);
builder.setFoo(b);
MyData myData = builder.build();
Window.alert(myData.getBar());
Window.alert(myData.getFoo());
}
The code compiles better (no setters):
builder = new Object();
builder.bar = 'a';
builder.foo = 'b';
myData = builder;
$wnd.alert(myData.bar);
$wnd.alert(myData.foo);
The biggest issue seemed to be that the inliner didn't introduce a
local variable for new Object(), and because of that, it correctly
concluded it couldn't keep copying that expression around. (I traced
through it having issues due to new having side effects.) Even if I
manually create a variable for the Builder at the outset, it still
doesn't help. (FYI, I am using new Object() instead of {} to work
around http://code.google.com/p/google-web-toolkit/issues/detail?id=3568
)
I was going to try to dig some more in to the inliner, but any ideas
how to improve this?
Will a later pass remove useless variable aliasing? (Seems like not
from my other example?) If so, I was thinking it might work to have
the inliner introduce a local all the time when it is trying to inline
a non-void function. Smarter methods are of course possible, but I
thought that might be worth a shot.
Any other ideas welcome. MyData class attached below. I tried a
variety of small tweaks to the MyData class and nothing made a
difference.
FYI, my eventual goal is:
var myData = {bar:'a',foo:'b'};
But that seems like an orthogonal optimization (and perhaps
generically useful).
Thanks for your interest, if you read this far,
-brian
PS: I am open to any changes to the MyData code below that a) preserve
the JSO-ness and b) leave the external API the same.
public static interface MyData {
String getFoo();
String getBar();
public static final class Builder extends JavaScriptObject
implements
[gwt-contrib] [google-web-toolkit commit] r5564 - Missed file from r5563
Author: fabb...@google.com
Date: Tue Jun 16 08:37:30 2009
New Revision: 5564
Modified:
trunk/doc/build.xml
Log:
Missed file from r5563
Review by: bobv
Modified: trunk/doc/build.xml
==
--- trunk/doc/build.xml (original)
+++ trunk/doc/build.xml Tue Jun 16 08:37:30 2009
@@ -7,7 +7,7 @@
property.ensure name=gwt.user.jar
location=${gwt.build.lib}/gwt-user.jar /
!-- Platform shouldn't matter here, just picking one --
- property.ensure name=gwt.dev.jar
location=${gwt.build.lib}/gwt-dev-linux.jar /
+ property.ensure name=gwt.dev.jar
location=${gwt.build.lib}/gwt-dev-${build.host.platform}.jar /
property name=USER_PKGS
value=com.google.gwt.animation.client;com.google.gwt.benchmarks.client;com.google.gwt.core.client;com.google.gwt.core.ext;com.google.gwt.core.ext.soyc;com.google.gwt.core.ext.linker;com.google.gwt.core.ext.typeinfo;com.google.gwt.debug.client;com.google.gwt.dom.client;com.google.gwt.event.dom.client;com.google.gwt.event.logical.shared;com.google.gwt.event.shared;com.google.gwt.http.client;com.google.gwt.i18n.client;com.google.gwt.i18n.client.constants;com.google.gwt.i18n.rebind.format;com.google.gwt.i18n.rebind.keygen;com.google.gwt.json.client;com.google.gwt.junit.client;com.google.gwt.benchmarks.client;com.google.gwt.user.client;com.google.gwt.user.client.rpc;com.google.gwt.user.client.ui;com.google.gwt.user.datepicker.client;com.google.gwt.user.server.rpc;com.google.gwt.xml.client/
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Make ClientBundle and CssResource generators faster
LGTM http://gwt-code-reviews.appspot.com/40804/diff/1/5 File user/src/com/google/gwt/resources/rebind/context/AbstractResourceContext.java (right): http://gwt-code-reviews.appspot.com/40804/diff/1/5#newcode43 Line 43: private static final MapTypeOracle, MapString, Object CACHES = new WeakHashMapTypeOracle, MapString, Object(); long line? http://gwt-code-reviews.appspot.com/40804 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Optimizing away the builder pattern
I am definitely for this kind of optimization, since GQuery is
effectively nothing but chained calls. However, I think the issue is
more complicated than just rewriting.
First, whether or not the optimization is an improvement depends on
subsequently whether or not the methods can be inlined. Thus, if
setA()/setB()/setC() can't be inlined, then you have increased code
size. This can occur because the methods might be polymorphic, they
might be too big, they might accidently evaluate the parameters in the
wrong order, etc.
Secondly, it doesn't appear to be as simple as checking for 'return
this'. Consider
public Builder setA(int val) {
if(isInvalid(val)) {
return this;
}
else {
return this;
}
}
vs
public Builder setA(int val) {
if(isInvalid(val)) {
return new Builder(this);
}
else {
return this;
}
}
vs
public Builder setA(int val) {
return UtilityClass.someMethod(this, val); // actually used by GQuery
}
I actually do think your proposal will work, although I'd feel much
better if it were more general purpose instead of tied so specifically
to a recognizable pattern, but I think the actual implementation may
be more tricky if you want to make it robust.
-Ray
On Tue, Jun 16, 2009 at 9:06 AM, Freeland Abbottfabb...@google.com wrote:
As I said, I hadn't looked at all into how feasible this was... but I was
hoping to do it by jiggering the Java AST, really, and not the JS one. That
is, I was looking to rewrite the Java from a chained
builder.setA().setB().setC() to multi-statement
builder.setA();builder.setB();builder.setC(), effectively unwinding any call
on the return value of a method returning this as a special-case pattern,
and let the Java-to-JavaScript compiler run from that.
On Tue, Jun 16, 2009 at 11:59 AM, Ray Cromwell cromwell...@gmail.com
wrote:
Even before the inliner gets it, a JSO chained expression like
a().b().c() is going to look like c(b(a())) so the inliner can only
inline the first call.
Automatically introducing temporaries would seem a lot harder. You'd
have to teach the compiler that 'this' is effectively final, and
therefore any method returning this, effectively always returns the
same value, regardless of side effects. Then, you'd have to introduce
the idea that the compiler can introduce temporaries (speculatively),
and later use common subexpression elimination to detect multiple
identical ones and hoist them out.
e.g.
c(b(a()))
becomes
var t1, t2, t3;
t1 = c(t2 = b(t3 = a()))
then, recognizing the that t1=t2=t3=builder=a() with copy propagation
t1 = builder
a(t1)
b(t1)
c(t1)
and now they can be inlined.
This just seems hard to me, since introducing temporaries is
speculative and you'd have introduce another pass to remove them in
the cases where they provided no benefit. However, this could end up
leading to infinite loops if you're not careful.
-Ray
On Mon, Jun 15, 2009 at 6:11 PM, Brian Stolerbsto...@google.com wrote:
Hi gwtc,
I was playing with using super-source to emulate some existing code
that uses a builder pattern and make it efficient in GWT as a
JavaScriptObject. I was hoping that the I could make the Builder just
compile away, but that doesn't seem to be happening. I started
debugging in JsInliner but started to get a bit lost. This is using
svn r5557 on trunk FYI (very recent).
What I am seeing is that if you use a chaining call pattern, the
inliner doesn't realize some of the optimization it can do.
Example usage code:
void example() {
MyData myData = MyData.Builder.create()
.setBar(a)
.setFoo(b).build();
Window.alert(myData.getBar());
Window.alert(myData.getFoo());
}
Output I get (extraneous bits removed, PRETTY mode):
function init(){
var myData;
myData = $setFoo($setBar(new Object(), 'a'), 'b');
$wnd.alert(myData.bar);
$wnd.alert(myData.foo);
}
function $setBar(this$static, s){
this$static.bar = s;
return this$static;
}
function $setFoo(this$static, s){
this$static.foo = s;
return this$static;
}
However, with this similar code:
void example2() {
MyData.Builder builder = MyData.Builder.create();
builder.setBar(a);
builder.setFoo(b);
MyData myData = builder.build();
Window.alert(myData.getBar());
Window.alert(myData.getFoo());
}
The code compiles better (no setters):
builder = new Object();
builder.bar = 'a';
builder.foo = 'b';
myData = builder;
$wnd.alert(myData.bar);
$wnd.alert(myData.foo);
The biggest issue seemed to be that the inliner didn't introduce a
local variable for new Object(), and because of that, it correctly
concluded it couldn't keep copying that expression around. (I traced
through it having issues due to new
[gwt-contrib] Re: Optimizing away the builder pattern
I've been pondering an SSA structure for the compiler that would make
some of this stuff a lot easier to deal with. Instead of keeping the
AST for the Java and JS trees around, we'd put everything into a
unified data flow graph in memory (with appropriate side-effect
barriers), optimize the graph, then reconstitute Java and JS code as
appropriate.
It's a huge undertaking, but there's some bonus end-results (some of
these fall out of the process of converting between AST and SSA forms:
- Many optimizations would now apply to both Java and JS code
- Cross-language Java-JS inlining and static evaluation would be
easier
- Easier inlining/common subexpression elimination
- More opportunities for static evaluation
- Incremental type tightening - the compiler could make more
methods static by knowing more about types/nullness deep within the
data flows: if (x instanceof Blah) { ((Blah)x).foo(); }
By traversing the data flow graph, the compiler would be able to see
that the JS object was effectively equivalent to the associative array
literal { 'a': 1, 'b': 2 } before it was even accessed by other code.
In cases where the developer is building other complex datastructures,
the compiler could potentially replace those with fully baked
equivalents as needed.
Matt.
On 16-Jun-09, at 9:59 AM, Ray Cromwell wrote:
Even before the inliner gets it, a JSO chained expression like
a().b().c() is going to look like c(b(a())) so the inliner can only
inline the first call.
Automatically introducing temporaries would seem a lot harder. You'd
have to teach the compiler that 'this' is effectively final, and
therefore any method returning this, effectively always returns the
same value, regardless of side effects. Then, you'd have to introduce
the idea that the compiler can introduce temporaries (speculatively),
and later use common subexpression elimination to detect multiple
identical ones and hoist them out.
e.g.
c(b(a()))
becomes
var t1, t2, t3;
t1 = c(t2 = b(t3 = a()))
then, recognizing the that t1=t2=t3=builder=a() with copy propagation
t1 = builder
a(t1)
b(t1)
c(t1)
and now they can be inlined.
This just seems hard to me, since introducing temporaries is
speculative and you'd have introduce another pass to remove them in
the cases where they provided no benefit. However, this could end up
leading to infinite loops if you're not careful.
-Ray
On Mon, Jun 15, 2009 at 6:11 PM, Brian Stolerbsto...@google.com
wrote:
Hi gwtc,
I was playing with using super-source to emulate some existing code
that uses a builder pattern and make it efficient in GWT as a
JavaScriptObject. I was hoping that the I could make the Builder just
compile away, but that doesn't seem to be happening. I started
debugging in JsInliner but started to get a bit lost. This is using
svn r5557 on trunk FYI (very recent).
What I am seeing is that if you use a chaining call pattern, the
inliner doesn't realize some of the optimization it can do.
Example usage code:
void example() {
MyData myData = MyData.Builder.create()
.setBar(a)
.setFoo(b).build();
Window.alert(myData.getBar());
Window.alert(myData.getFoo());
}
Output I get (extraneous bits removed, PRETTY mode):
function init(){
var myData;
myData = $setFoo($setBar(new Object(), 'a'), 'b');
$wnd.alert(myData.bar);
$wnd.alert(myData.foo);
}
function $setBar(this$static, s){
this$static.bar = s;
return this$static;
}
function $setFoo(this$static, s){
this$static.foo = s;
return this$static;
}
However, with this similar code:
void example2() {
MyData.Builder builder = MyData.Builder.create();
builder.setBar(a);
builder.setFoo(b);
MyData myData = builder.build();
Window.alert(myData.getBar());
Window.alert(myData.getFoo());
}
The code compiles better (no setters):
builder = new Object();
builder.bar = 'a';
builder.foo = 'b';
myData = builder;
$wnd.alert(myData.bar);
$wnd.alert(myData.foo);
The biggest issue seemed to be that the inliner didn't introduce a
local variable for new Object(), and because of that, it correctly
concluded it couldn't keep copying that expression around. (I traced
through it having issues due to new having side effects.) Even if I
manually create a variable for the Builder at the outset, it still
doesn't help. (FYI, I am using new Object() instead of {} to work
around http://code.google.com/p/google-web-toolkit/issues/detail?id=3568)
I was going to try to dig some more in to the inliner, but any ideas
how to improve this?
Will a later pass remove useless variable aliasing? (Seems like not
from my other example?) If so, I was thinking it might work to have
the inliner introduce a local all the time when it is trying to
inline
a
[gwt-contrib] Re: Optimizing away the builder pattern
I prototyped a piece of this a couple of months ago in an attempt to
work out how to build an immediate dominator tree so as to perfectly
prune clinits. The problem is, you'd have to practically rewrite the
entire compiler. I think at this point, it's a little too much, maybe
something for GWT 3.0.
My middle ground was to consider a sort of 'overlay' SSA to gather
information for optimizations in the AST. That is, process the AST and
build up an SSA IR, and then use that to compute information needed
for optimizations later (e.g. dominator tree). Then, you do the
optimizations on the AST and choose optimizations which do not violate
invariants that would cause the need to recompute the auxiliary IR.
For example, in the case of dominators, there are known optimizations
which do not change dominance relationships, so are safe to do and
allow you to cache that information.
Another possibility is to do value numbering instead of SSA. You could
process blocks and value number all assignments. Afterwards, you can
efficiently detect use-def patterns and use this for copy-prop, cse,
dead removal. Finally, you follow up with a 'register allocator' pass
that renames all the values back by allocating symbols as needed
according to liveness ranges.
For example, something like
String s1 = Hello:
Window.alert(s1);
String s2 = World;
Window.alert(s2);
would become
String s1 = Hello;
Window.alert(s1);
s1 = World;
Window.alert(s2);
This would eliminate a 'var' declaration from the JS, which should
have some benefit to both size and speed.
-Ray
On Tue, Jun 16, 2009 at 10:27 AM, Matt Mastraccimatt...@mastracci.com wrote:
I've been pondering an SSA structure for the compiler that would make
some of this stuff a lot easier to deal with. Instead of keeping the
AST for the Java and JS trees around, we'd put everything into a
unified data flow graph in memory (with appropriate side-effect
barriers), optimize the graph, then reconstitute Java and JS code as
appropriate.
It's a huge undertaking, but there's some bonus end-results (some of
these fall out of the process of converting between AST and SSA forms:
- Many optimizations would now apply to both Java and JS code
- Cross-language Java-JS inlining and static evaluation would be
easier
- Easier inlining/common subexpression elimination
- More opportunities for static evaluation
- Incremental type tightening - the compiler could make more
methods static by knowing more about types/nullness deep within the
data flows: if (x instanceof Blah) { ((Blah)x).foo(); }
By traversing the data flow graph, the compiler would be able to see
that the JS object was effectively equivalent to the associative array
literal { 'a': 1, 'b': 2 } before it was even accessed by other code.
In cases where the developer is building other complex datastructures,
the compiler could potentially replace those with fully baked
equivalents as needed.
Matt.
On 16-Jun-09, at 9:59 AM, Ray Cromwell wrote:
Even before the inliner gets it, a JSO chained expression like
a().b().c() is going to look like c(b(a())) so the inliner can only
inline the first call.
Automatically introducing temporaries would seem a lot harder. You'd
have to teach the compiler that 'this' is effectively final, and
therefore any method returning this, effectively always returns the
same value, regardless of side effects. Then, you'd have to introduce
the idea that the compiler can introduce temporaries (speculatively),
and later use common subexpression elimination to detect multiple
identical ones and hoist them out.
e.g.
c(b(a()))
becomes
var t1, t2, t3;
t1 = c(t2 = b(t3 = a()))
then, recognizing the that t1=t2=t3=builder=a() with copy propagation
t1 = builder
a(t1)
b(t1)
c(t1)
and now they can be inlined.
This just seems hard to me, since introducing temporaries is
speculative and you'd have introduce another pass to remove them in
the cases where they provided no benefit. However, this could end up
leading to infinite loops if you're not careful.
-Ray
On Mon, Jun 15, 2009 at 6:11 PM, Brian Stolerbsto...@google.com
wrote:
Hi gwtc,
I was playing with using super-source to emulate some existing code
that uses a builder pattern and make it efficient in GWT as a
JavaScriptObject. I was hoping that the I could make the Builder just
compile away, but that doesn't seem to be happening. I started
debugging in JsInliner but started to get a bit lost. This is using
svn r5557 on trunk FYI (very recent).
What I am seeing is that if you use a chaining call pattern, the
inliner doesn't realize some of the optimization it can do.
Example usage code:
void example() {
MyData myData = MyData.Builder.create()
.setBar(a)
.setFoo(b).build();
Window.alert(myData.getBar());
Window.alert(myData.getFoo());
}
Output I get (extraneous bits removed, PRETTY mode):
function init(){
var
[gwt-contrib] Re: RR : Make ClientBundle and CssResource generators faster
Thanks for the review. Committed at r5566. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on CssResource in google-web-toolkit
Comment by poornimachandran123: @Strict annotation will prove to boon and an error free system. For more information: http://code.google.com/p/google-web-toolkit/wiki/CssResource --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5565 - Edited wiki page through web user interface.
Author: fabb...@google.com
Date: Tue Jun 16 10:17:46 2009
New Revision: 5565
Modified:
wiki/DefaultLocaleBinding.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/DefaultLocaleBinding.wiki
==
--- wiki/DefaultLocaleBinding.wiki (original)
+++ wiki/DefaultLocaleBinding.wiki Tue Jun 16 10:17:46 2009
@@ -32,7 +32,7 @@
= Implementation Requirements =
-The fallback value would be stored in a new filed of `BindingProperty`,
with a public getter, default setter, and default value of . The
interesting changes happen in the property provider, which would use a
template syntax in the property provider !JavaScript and
`getPropertyProvider()` would do template substitution, so that a property
provider of
+The fallback value would be stored in a new filed of `BindingProperty`,
with a public getter, default setter, and default value of . The
interesting changes happen in the two `SelectionProperty` classes,
particularly `com.google.gwt.core.ext.linker.SelectionProperty`, which
would use a template syntax in the property provider !JavaScript and
`getPropertyProvider()` would do template substitution, so that a property
provider of
{{{
while (!__gwt_isKnownPropertyValue(locale, locale)) {
@@ -63,4 +63,8 @@
Also note that the substitution token is, if somehow seen by
naive !JavaScript, merely a comment (much as JSNI is for Java code). In
this particular example, moreover, the token is inside a string literal, so
a naive interpreter would merely see a very odd-looking (and in fact
invalid) locale string.
-Other uses might include setting a default logging configuration, which
user modules could modify. Not allowed by this scheme would be having a
fallback that depended on any other input. The fallback value _could_ be
arbitrary !JavaScript, if the property provider were written to execute the
extracted value (whether as a string or as non-quoted code). I see few
uses for that, but perhaps the default logging might depend on the
client's subnet, or on a combination of query inputs for different logging
areas.
\ No newline at end of file
+Other uses might include setting a default logging configuration, which
user modules could modify. Not allowed by this scheme would be having a
fallback that depended on any other input. The fallback value _could_ be
arbitrary !JavaScript, if the property provider were written to execute the
extracted value (whether as a string or as non-quoted code). I see few
uses for that, but perhaps the default logging might depend on the
client's subnet, or on a combination of query inputs for different logging
areas.
+
+I also propose to make the fallback value visible to generators, via
`com.google.gwt.core.SelectionProperty.getFallback()`. This is so that the
`AbstractResourceImplCreator` can recognize which actual permutation is
the default one, as some generators might run only in the default locale
but users might sensibly use `set-property/` to eliminate the literal
value default.
+
+(_Note_: why do we have two such similar classes? It seems one is for
access by linkers, the other by generators, to respective subsets of
`BindingProperty` data; is there enough distinction, and should we at least
have more differentiated names?)
\ No newline at end of file
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Optimizing away the builder pattern
A very interesting idea, a sort of hybrid AST/SSA (hmm, I recall GCC
now has some kind of 'Tree SSA' too) although I think the real win
wouldn't come until you could replace conditionals like
JWhile/JIf/JFor with their SSA equivalents.The reason being, you'd be
limited from doing intra-block flow analysis without it, so only small
methods would benefit.
Ah, here's the paper I remember reading:
http://www.airs.com/dnovillo/Papers/tree-ssa-gccs03-slides.pdf I
think this could seriously be adapted for GWT, and using your idea of
incrementally doing it, I think would work to get experimental results
without blowing up the existing architecture.
-Ray
On Tue, Jun 16, 2009 at 11:11 AM, Matt Mastraccimatt...@mastracci.com wrote:
Could we build out SSA incrementally (brainstorming a bit here)?
Maybe start by replacing the Java and JS expressions with their SSA
equivalent in the tree? The consecutive JExpressionStatements in a
JBlock or JsBlock could be extracted into SSA form and inserted as a
new type of statement - JSsaStatement. This would let us perform all
the SSA analysis on a limited scale without having to rewrite the
whole compiler - just the parts that operate on JExpressions.
BTW, value numbering looks like a quick win to me. Reusing locals has
another additional benefit - it allows the browser to GC values at
reassignment time, rather than waiting for the scope to exit (which
may be far in the future in the case of closures).
On 16-Jun-09, at 11:49 AM, Ray Cromwell wrote:
I prototyped a piece of this a couple of months ago in an attempt to
work out how to build an immediate dominator tree so as to perfectly
prune clinits. The problem is, you'd have to practically rewrite the
entire compiler. I think at this point, it's a little too much, maybe
something for GWT 3.0.
My middle ground was to consider a sort of 'overlay' SSA to gather
information for optimizations in the AST. That is, process the AST and
build up an SSA IR, and then use that to compute information needed
for optimizations later (e.g. dominator tree). Then, you do the
optimizations on the AST and choose optimizations which do not violate
invariants that would cause the need to recompute the auxiliary IR.
For example, in the case of dominators, there are known optimizations
which do not change dominance relationships, so are safe to do and
allow you to cache that information.
Another possibility is to do value numbering instead of SSA. You could
process blocks and value number all assignments. Afterwards, you can
efficiently detect use-def patterns and use this for copy-prop, cse,
dead removal. Finally, you follow up with a 'register allocator' pass
that renames all the values back by allocating symbols as needed
according to liveness ranges.
For example, something like
String s1 = Hello:
Window.alert(s1);
String s2 = World;
Window.alert(s2);
would become
String s1 = Hello;
Window.alert(s1);
s1 = World;
Window.alert(s2);
This would eliminate a 'var' declaration from the JS, which should
have some benefit to both size and speed.
-Ray
On Tue, Jun 16, 2009 at 10:27 AM, Matt
Mastraccimatt...@mastracci.com wrote:
I've been pondering an SSA structure for the compiler that would make
some of this stuff a lot easier to deal with. Instead of keeping the
AST for the Java and JS trees around, we'd put everything into a
unified data flow graph in memory (with appropriate side-effect
barriers), optimize the graph, then reconstitute Java and JS code as
appropriate.
It's a huge undertaking, but there's some bonus end-results (some of
these fall out of the process of converting between AST and SSA
forms:
- Many optimizations would now apply to both Java and JS code
- Cross-language Java-JS inlining and static evaluation would be
easier
- Easier inlining/common subexpression elimination
- More opportunities for static evaluation
- Incremental type tightening - the compiler could make more
methods static by knowing more about types/nullness deep within the
data flows: if (x instanceof Blah) { ((Blah)x).foo(); }
By traversing the data flow graph, the compiler would be able to see
that the JS object was effectively equivalent to the associative
array
literal { 'a': 1, 'b': 2 } before it was even accessed by other code.
In cases where the developer is building other complex
datastructures,
the compiler could potentially replace those with fully baked
equivalents as needed.
Matt.
On 16-Jun-09, at 9:59 AM, Ray Cromwell wrote:
Even before the inliner gets it, a JSO chained expression like
a().b().c() is going to look like c(b(a())) so the inliner can only
inline the first call.
Automatically introducing temporaries would seem a lot harder. You'd
have to teach the compiler that 'this' is effectively final, and
therefore any method returning this, effectively always returns the
same value, regardless of side effects. Then, you'd have to
[gwt-contrib] [google-web-toolkit commit] r5567 - Fix missing file in r5566.
Author: b...@google.com
Date: Tue Jun 16 12:25:57 2009
New Revision: 5567
Modified:
trunk/user/test/com/google/gwt/resources/rg/CssTestCase.java
Log:
Fix missing file in r5566.
Modified: trunk/user/test/com/google/gwt/resources/rg/CssTestCase.java
==
--- trunk/user/test/com/google/gwt/resources/rg/CssTestCase.java
(original)
+++ trunk/user/test/com/google/gwt/resources/rg/CssTestCase.javaTue Jun
16
12:25:57 2009
@@ -55,19 +55,19 @@
}
@Override
-protected void doAcceptWithInsertRemove(List? extends CssNode list) {
- for (CssNode node : list) {
-doAccept(node);
- }
-}
-
-@Override
protected T extends CssNode T doAccept(T node) {
assertFalse(Found repeated node + node.toString(),
seen.containsKey(node));
seen.put(node, null);
return super.doAccept(node);
}
+
+@Override
+protected void doAcceptWithInsertRemove(List? extends CssNode list) {
+ for (CssNode node : list) {
+doAccept(node);
+ }
+}
}
/**
@@ -84,6 +84,14 @@
return null;
}
+public T T getCachedData(String key, ClassT clazz) {
+ return null;
+}
+
+public JClassType getClientBundleType() {
+ return null;
+}
+
public GeneratorContext getGeneratorContext() {
return null;
}
@@ -93,8 +101,8 @@
return null;
}
-public JClassType getClientBundleType() {
- return null;
+public T boolean putCachedData(String key, T value) {
+ return false;
}
public boolean supportsDataUrls() {
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Allow user-provided bridge classes in hosted mode
LGTM with nits. http://gwt-code-reviews.appspot.com/34836/diff/1001/2002 File dev/core/src/com/google/gwt/dev/shell/rewrite/HasAnnotation.java (right): http://gwt-code-reviews.appspot.com/34836/diff/1001/2002#newcode29 Line 29: * a type. Should mention the annotation has to be directly on the type without considering inheritance (perhaps on the hasAnnotation method instead of here). http://gwt-code-reviews.appspot.com/34836/diff/1001/2002#newcode50 Line 50: boolean found; private? http://gwt-code-reviews.appspot.com/34836/diff/1001/2003 File dev/core/super/com/google/gwt/core/client/BridgeClass.java (right): http://gwt-code-reviews.appspot.com/34836/diff/1001/2003#newcode26 Line 26: * super-source. Still not sold on the name, but can't think of anything better. If this is intended to be something that external code might use, there should probably be more documentation and an example. If not, it should probably be documented as such. http://gwt-code-reviews.appspot.com/34836/diff/1001/2005 File user/test-super/com/google/gwt/dev/jjs/super/com/google/gwt/dev/jjs/bridge/UserBridgeClass.java (right): http://gwt-code-reviews.appspot.com/34836/diff/1001/2005#newcode32 Line 32: * Test cross-bounday method invocation. typo http://gwt-code-reviews.appspot.com/34836/diff/1001/2009 File user/test/com/google/gwt/dev/jjs/bridge/UserBridgeClass.java (right): http://gwt-code-reviews.appspot.com/34836/diff/1001/2009#newcode33 Line 33: * Test cross-bounday method invocation. typo: bounday http://gwt-code-reviews.appspot.com/34836 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5568 - Changes to make GWT i18n support real default locales. Introduces a .gwt.xml tag set-...
Author: fabb...@google.com
Date: Tue Jun 16 14:20:27 2009
New Revision: 5568
Added:
trunk/dev/core/test/com/google/gwt/core/ext/linker/impl/
trunk/dev/core/test/com/google/gwt/core/ext/linker/impl/StandardSelectionPropertyTest.java
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/SelectionProperty.java
trunk/dev/core/src/com/google/gwt/core/ext/linker/SelectionProperty.java
trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/StandardSelectionProperty.java
trunk/dev/core/src/com/google/gwt/dev/cfg/BindingProperty.java
trunk/dev/core/src/com/google/gwt/dev/cfg/ModuleDefSchema.java
trunk/dev/core/src/com/google/gwt/dev/cfg/StaticPropertyOracle.java
trunk/dev/core/src/com/google/gwt/dev/shell/ModuleSpacePropertyOracle.java
trunk/samples/i18n/src/com/google/gwt/sample/i18n/I18N.gwt.xml
trunk/user/src/com/google/gwt/i18n/I18N.gwt.xml
trunk/user/src/com/google/gwt/i18n/rebind/AbstractLocalizableImplCreator.java
Log:
Changes to make GWT i18n support real default locales. Introduces
a .gwt.xml tag set-property-fallback name=prop value=chosenvalue/,
which can be used in property providers as a template substitution for
/*-FALLBACK-*/. In i18n, this is used to select a real locale to be
returned in situations when default would otherwise have been used. Also
modified AbstractLocalizableImplCreator so that generators running in
GwtLocale.DEFAULT will run on this real locale, even if set-property
has been used so that the literal default is not being generated.
Review by: jat
Modified: trunk/dev/core/src/com/google/gwt/core/ext/SelectionProperty.java
==
--- trunk/dev/core/src/com/google/gwt/core/ext/SelectionProperty.java
(original)
+++ trunk/dev/core/src/com/google/gwt/core/ext/SelectionProperty.java Tue
Jun 16 14:20:27 2009
@@ -19,7 +19,10 @@
import java.util.SortedSet;
/**
- * A named deferred binding (property, value) pair.
+ * A named deferred binding (property, value) pair for use in generators.
+ *
+ * @see com.google.gwt.core.ext.linker.SelectionProperty A similarly-named
+ * analog for linkers.
*/
public interface SelectionProperty {
@@ -38,9 +41,15 @@
String getCurrentValue();
/**
+ * Gets the fallback value for the property
+ * @return the fallback, or
+ */
+ String getFallbackValue();
+
+ /**
* Returns the possible values for the property in sorted order.
*
* @return a SortedSet of Strings containing the possible property
values.
*/
- SortedSetString getPossibleValues();
+ SortedSetString getPossibleValues();
}
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/linker/SelectionProperty.java
==
---
trunk/dev/core/src/com/google/gwt/core/ext/linker/SelectionProperty.java
(original)
+++
trunk/dev/core/src/com/google/gwt/core/ext/linker/SelectionProperty.java
Tue Jun 16 14:20:27 2009
@@ -22,6 +22,9 @@
* may not have a single value applied across all permutations.
*
* SelectionProperty implementations must support object identity
comparisons.
+ *
+ * @see com.google.gwt.core.ext.SelectionProperty A similarly-named
interface used
+ * in generators.
*/
public interface SelectionProperty {
/**
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/StandardSelectionProperty.java
==
---
trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/StandardSelectionProperty.java
(original)
+++
trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/StandardSelectionProperty.java
Tue Jun 16 14:20:27 2009
@@ -28,6 +28,8 @@
* {...@link BindingProperty}.
*/
public class StandardSelectionProperty implements SelectionProperty {
+ private static final String FALLBACK_TOKEN = /*-FALLBACK-*/;
+
private final String activeValue;
private final String name;
private final String provider;
@@ -40,7 +42,9 @@
activeValue = null;
}
name = p.getName();
-provider = p.getProvider() == null ? null : p.getProvider().getBody();
+String fallback = p.getFallback();
+provider = p.getProvider() == null ? null :
+p.getProvider().getBody().replace(FALLBACK_TOKEN, fallback);
values = Collections.unmodifiableSortedSet(new TreeSetString(
Arrays.asList(p.getDefinedValues(;
}
Modified: trunk/dev/core/src/com/google/gwt/dev/cfg/BindingProperty.java
==
--- trunk/dev/core/src/com/google/gwt/dev/cfg/BindingProperty.java
(original)
+++ trunk/dev/core/src/com/google/gwt/dev/cfg/BindingProperty.java Tue Jun
16 14:20:27 2009
@@ -27,9 +27,12 @@
*/
public class BindingProperty extends Property {
+ private static final String EMPTY = ;
+
[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT
Cameron, were you at Google I/O or did you sign up for the sandbox? I can ask a Googler to invite you if not. -Ray On Mon, Jun 15, 2009 at 6:21 PM, Cameron Braid came...@braid.com.au wrote: 2009/6/16 Bruce Johnson br...@google.com I'm starting to make a bit o' progress on this. I'll send out a design doc real soon now. BTW, anyone on the Contributors list here have Wave sandbox accounts? Sure would be easier to discuss this in a wave... No :( But if you are offering invites, send one this way :) Otherwise, its probably wise to keep the discussion in a place where all interested parties can participate. Cam --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: inliner handles implicit long cast at method return
LGTM http://gwt-code-reviews.appspot.com/39805 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Reducing noise in GWT compiler output
That would be marvelous. I hadn't thought through the implications of IHM, but it seems like it might solve the problem. What about types that aren't IHM compatible, such as those containing JSNI? Could those still cause spurious errors? On Tue, Jun 16, 2009 at 6:29 PM, Scott Blum sco...@google.com wrote: Instant hosted mode should really change the game, right? We will no longer be speculatively compiling anything for TypeOracle since we'll be using class files that should already exist. On Mon, Jun 15, 2009 at 11:21 PM, John Tamplin j...@google.com wrote: On Mon, Jun 15, 2009 at 11:11 PM, Bruce Johnson br...@google.com wrote: We've known for a while that the GWT compiler is spammy, even at default log levels. There is a reason for this behavior, believe it or not: TypeOracle's JClassType#getSubtypes() call. Because generators can ask for the subtypes of any type, the compiler has to parse essentially everything, not just those types that are statically reachable from a module's entry point(s). We sometimes refer to it as speculative parsing. Overall, the behavior is vitally useful for code generators, especially RPC and I18n, and it's generally useful anytime you need to do something factory-like, where you might have used Class.forName() if it were available. So, I'm not proposing that we change that behavior. The problem is that in the process of speculatively parsing everything on the client source path, inevitably we end up encountering source files that can't actually be meaninfully compiled given the current client source path and other various reasons for mismatches. It can happen when you have more than one module.gwt.xml in the same location with different sets of inherited modules. We ought to find a way to keep quieter about problems we find during that speculative parse. We want to *not* spam the log when the source file was found speculatively but definitely still report errors when they really are relevant to getting a clean compile. This isn't as simple as it might sound. It isn't just a how do we code it question. Imagine you have a GWT module that needs RPC. Because RPC can use polymorphism, you might have an RPC method whose return type is Shape (vs. concrete subtypes Circle, Square, Triangle). This is handled magically in the GWT RPC generator because it can see those subtypes of Shape and quietly generate deserializers in the generated RPC proxy. The tricky bit is when Circle.java has a syntax error, say. The type Circle won't be found as a subtype of Shape in the type oracle, so the GWT RPC generator won't know to emit a deserializer for it. (To be precise, it won't even know that it *ought* to try to do so.) We have a choice: either we emit a string of non-fatal errors regarding the failure to parse Circle.java or we don't. If we do, we get the spam we hate today, but at least we've informed the developer that something fishy may happen, since it wasn't a perfectly clean compile. If we don't emit such errors, then a module will quietly appear to compile, even when there are compilation problems that might affect the intended behavior (in this case, when a server responds to the client with a Circle object, the client won't know how to deserialize it). All that said, I don't think it will be big a problem in practice if we log less and risk the kind of surprise failure I described with something like RPC. After all, javac (or your IDE) would complain about Cirlce.java not compiling anyway, so the only real failure mode happens if you *only* compile with the GWT compiler -- and that seems pretty unlikely, especially if you're working in an IDE. Here's a proposal for the new behavior. When the GWT compile invokes JDT to do the front-end compile, capture the errors in an in-memory data structure (keyed by type name?) but do not log them right away. After the JDT front-end compile settles, create a set of known statically reachable types from the entry point classes (the entry point classes are reachable from themselves by definition). Only log errors on compilation unit in that set of dependencies, and do not log errors in an other case. Anybody see any problems with this idea? I think this would omit log messages that make you say, What on earth does NumberFormat_fr_Test.java have to do with my compiling Hello.java? How does that fit with instant hosted mode? -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on UsingOOPHM in google-web-toolkit
Comment by googelybear: When I try to start it (Main class=com.google.gwt.dev.HostedMode) I get: Exception in thread main java.lang.NoSuchMethodError: com.google.gwt.core.ext.ServletContainerLauncher.getName()Ljava/lang/String; at com.google.gwt.dev.HostedMode.getWebServerName(HostedMode.java:417) at com.google.gwt.dev.OophmHostedModeBase.openAppWindow(OophmHostedModeBase.java:408) at com.google.gwt.dev.HostedModeBase.doStartup(HostedModeBase.java:471) at com.google.gwt.dev.OophmHostedModeBase.doStartup(OophmHostedModeBase.java:333) at com.google.gwt.dev.HostedMode.doStartup(HostedMode.java:345) at com.google.gwt.dev.HostedModeBase.startUp(HostedModeBase.java:585) at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:397) at com.google.gwt.dev.HostedMode.main(HostedMode.java:247) any ideas what I'm doing wrong? I just put the gwt-dev-oophm.jar at the beginning of my classpath. For more information: http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on UsingOOPHM in google-web-toolkit
Comment by tamplinjohn: Are you trying to use it with GWT 1.6? That isn't going to work. For more information: http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Reducing noise in GWT compiler output
On Tue, Jun 16, 2009 at 6:29 PM, Scott Blum sco...@google.com wrote: Instant hosted mode should really change the game, right? We will no longer be speculatively compiling anything for TypeOracle since we'll be using class files that should already exist. The problem is that if there is no class file, we don't know it was because compilation failed -- it could just be they aren't using an IDE -- so we have to compile from source in that case, which would still generate all the errors. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT
Matt,
I created a Wave Advanced GWT Compiler Optimizations and invited
you to it. Anyone who sends me their sandbox ID, I will invite. I am
using it to collect non-trivial optimizations in an outline draft
where we can discuss them. As a first pass, I entered the idea of
Hybrid-SSA/Tree-SSA/Expression-only SSA with examples of how it can be
used to do better block level optimization.
-Ray
On Mon, Jun 15, 2009 at 7:09 PM, Matt Mastraccimatt...@mastracci.com wrote:
I do as well - I'm mmastrac.
On 15-Jun-09, at 8:02 PM, Ray Cromwell wrote:
I do, cromwellian is my id on the sandbox.
-Ray
On Mon, Jun 15, 2009 at 6:14 PM, Bruce Johnsonbr...@google.com
wrote:
I'm starting to make a bit o' progress on this. I'll send out a
design doc
real soon now.
BTW, anyone on the Contributors list here have Wave sandbox
accounts? Sure
would be easier to discuss this in a wave...
On Mon, Jun 15, 2009 at 7:54 PM, Stefan Haustein
haust...@google.com
wrote:
Ray,
I think we can improve the class over time -- any reasonable
starting
point (even without iterators or with non-optimal iterators) would
help
significantly.
Stefan
On Sat, Jun 13, 2009 at 4:21 AM, Ray Cromwell
cromwell...@gmail.com
wrote:
BTW, the last proposal is very unsafe with some form of escape
analysis since it is unsafe to pass references to classes which
reference local scope to other scopes. Another possibility is a
form
of 'destructuring' of Iterator classes by inlining them completely
into local scope vs escape analysis and then forgoing separate
construction.
A simpler way to maintain for-each with JRE collections without
creating objects is to change the way that for-each deals with
IterableT when T is a List.
The compiler could change:
for(T x : foo) { ... }
where foo is a ListT
into
for(int i=0; ifoo.size(); ++i) {
T x = foo.get(i);
}
instead of calling foo.iterator() and using Iterator methods.
-Ray
On Fri, Jun 12, 2009 at 7:31 PM, Ray
Cromwellcromwell...@gmail.com
wrote:
I'm in the process of some final tweaks on GQuery, so I'll look
at how
much of my private JSArray class I can move over as a patch.
One possibility for avoiding Iterator object creation without
using
flyweights is to introduce a new Iterator type which contains
methods
which are parameterized by the collection and which use my
Extension
Method/Category method JSO trick.
public class FastIteratorT extends JavaScriptObject {
protected FastIterator() {}
public S, T extends ListS FastIteratorS make(TS list) {
return (FastIteratorS)(GWT.isScript() ? makeWeb() :
makeHosted());
}
private final native FastIterator makeWeb() /*-{
return 0;
}-*/;
private final native FastIterator makeHosted() /*-{
return [0];
}-*/;
public final int value() {
return GWT.isScript() ? valueWeb() : valueHosted();
}
public native int valueWeb() /*-{
return this;
}-*/;
public native int valueHosted() /*-{
return this[0];
}-*/;
public native hasNext(ListT list) {
return value() list.size();
}
public native T next(ListT list) {
return list.get(value()++); // unsure if using value() as
rvalue
will work here
}
}
then you should be able to write code like
ListString foo = getList();
FastIteratorString iter = FastIterator.make(foo);
while(iter.hasNext(foo)) {
String s = iter.next(foo);
}
Why doesn't this create any additional objects? Because
'iter'/FastIterator is actually a native JS number/scalar type,
and
what this is really doing is simulating the addition of
hasNext()/next() to the number's prototype.
We could dispense with the need for an additional parameter if
GWT had
a magic method for allocating new local variables/symbols in the
local
scope. Imagine if writing
VariableT x = GWT.createVariable(0);
was a magic method that just generated a 'var x = 0'
declaration, only
it promised to always be inlined and do so in the caller's scope.
'Variable' would be a magic class that never creates fields on the
actual object themselves and are pruned/removed at runtime.
Then you could have FastIterator impersonate a reference to the
underlying ListT, and rewrite hasNext()/next() as:
VariableInt x = GWT.createVariableInt(0);
public boolean hasNext() {
return x.get() this.size();
}
public T next() {
return this.get(x.get()++); // or x.postIncrement()
}
this would produce code that would create no additional objects as
well as maintain Iterator-like interface.
-Ray
On Thu, Jun 11, 2009 at 7:25 AM, Stefan Hausteinhaust...@google.com
wrote:
+1 Ray
Could you contribute your implementation(s)?
On Thu, Jun 11, 2009 at 12:51 PM, Joel Webber j...@google.com
wrote:
+1 Ray. Now here's the really tricky question. Is there any
way we
can
take advantage of Javascript's for (x in y) { ... } syntax
(and
should we,
given its spotty performance)? My intuition tells me that the
only
[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT
Unfortunately I wasn't able to attend Google I/O, however I did watch a few of the sessions online. I signed up for the sandbox, but it appears that google aren't going to grant access to non IO attendees for a little while yet. I'd appreciate an invite, but I understand if that's not feasible. Cheers Cameron 2009/6/17 Ray Cromwell cromwell...@gmail.com Cameron, were you at Google I/O or did you sign up for the sandbox? I can ask a Googler to invite you if not. -Ray On Mon, Jun 15, 2009 at 6:21 PM, Cameron Braid came...@braid.com.auwrote: 2009/6/16 Bruce Johnson br...@google.com I'm starting to make a bit o' progress on this. I'll send out a design doc real soon now. BTW, anyone on the Contributors list here have Wave sandbox accounts? Sure would be easier to discuss this in a wave... No :( But if you are offering invites, send one this way :) Otherwise, its probably wise to keep the discussion in a place where all interested parties can participate. Cam --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Allow user-provided bridge classes in hosted mode
@Scott, Per our IM conversation, I've renamed the new concept to GwtScriptOnly. Could you check this over once more before I commit it? @John, Thanks for the review. http://gwt-code-reviews.appspot.com/34836 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] NoSuchMethodError with latest build of Trunk
I am getting this error after downloading the latest rev from the trunk (5568?). I get the same error in Hosted Browser and OOPHM. java.lang.NoSuchMethodError: com.google.gwt.dev.shell.StandardGeneratorContext.init(Lcom/google/ gwt/dev/javac/CompilationState;Lcom/google/gwt/dev/cfg/ PublicOracle;Ljava/io/File;Ljava/io/File;Lcom/google/gwt/core/ext/ linker/ArtifactSet;)V at com.google.gwt.dev.shell.ShellModuleSpaceHost.onModuleReady (ShellModuleSpaceHost.java:93) at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:324) at com.google.gwt.dev.shell.BrowserWidget.attachModuleSpace (BrowserWidget.java:343) at com.google.gwt.dev.shell.moz.BrowserWidgetMoz.access$100 (BrowserWidgetMoz.java:35) at com.google.gwt.dev.shell.moz.BrowserWidgetMoz $ExternalObjectImpl.gwtOnLoad(BrowserWidgetMoz.java:58) at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java: 1428) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2840) at com.google.gwt.dev.SwtHostedModeBase.processEvents (SwtHostedModeBase.java:297) at com.google.gwt.dev.HostedModeBase.pumpEventLoop (HostedModeBase.java:565) at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:411) at com.google.gwt.dev.HostedMode.main(HostedMode.java:243) Working in Eclipse with 32-bit ubuntu 8.10. Any help would be appreciated. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT
I agree, although I find having a wiki with inline response rather convenient. Here is what I have so far from the Wave, at the end, there is a possible to solution to the problem of optimizing away the builder pattern using general purpose optimizations. -Ray Advanced GWT Compiler Optimizations The purpose of this wave is to talk about a list of future compiler improvements / optimizations for GWT that go beyond the scope of those listed in the current project wiki. Hybrid Intermediate Representations (Tree SSA) Control Flow / Data Flow Analysis Common Subexpression Elimination / Partial Redundancy Elimination Block Level Dead Code Elimination Copy Propagation Register Allocation (temporary/local reduction) Escape Analysis Object inlining / Destructuring Speculative Inlining/Function Cloning Efficient Anonymous Inner Classes Loop Hoisting / Loop Induction Intermediate Representations In order to perform many optimizations, it is easier to deal with a flatter data structure than the traditional AST such as the traditional three address code, but using pure three address code for everything has its own downsides, as well as requiring substantial changes to the compiler. Matt M suggested a hybrid approach of only converting JExpressions to SSA form, This would have the benefit of localizing the changes. It reminded me of GCC's Tree SSA, which upon re-review, looks like it can offer us some useful lessons. As an example, consider the expression x = a + b + c + d in the current AST, this will look something like (assign x (+ d (+ c (+ a b. We can flatten this by introducing temporaries, arriving at: t1 = a + b t2 = t1 + c t3 = t2 + d x = t3 In addition, if we are only dealing with simple blocks (no branches), we can use a more simpler kind of SSA, which is simply to rename variables on assignment. Thus, if you have x = 1 y = 2 z = x + y x++ y++ z = x + y you can rename each variable on assignment, yielding the following x1 = 1 y1 = 2 z1 = x1 + y1 x2 = x1 + 1 y2 = y1 + 1 z2 = x2 + y2 This produces an SSA-like form, with each variable defined only once. At first glance, it looks like a de-optimization, but a later pass that does constant folding, copy propagation, and dead elimination will clean this up. As an example, after copy propagation x1 = 1 y1 = 1 z1 = 1 + 2 x2 = 1 + 1 y2 = 2 + 1 z2 = x2 + y2 after constant folding x1 = 1 y1 = 1 z1 = 3 x2 = 2 y2 = 3 z2 = x2 + y2 after DCE (x1/y1/z1 no longer referenced) x2 = 2 y2 = 3 z2 = x2 + y2 after copy prop x2 = 2 y2 = 3 z2 = 2 + 3 after constant fold x2 = 2 y2 = 3 z2 = 5 after DCE z2 = 5 Finally, after renaming registers back to their original names z = 5 A register allocation style pass can further eliminate temporaries later. However, do to proper CFA/DFA, we may want to build a real SSA form, complete with phi functions, so we may do cross-block optimizations. Effects on the Builder Pattern Another recent list discussion concerned optimizing the Builder Pattern. Flattening the AST and using SSA techniques can have a positive effect on this as well. Consider: Builder b = new Builder(); b.setA(10).setB(20).setC(30); After conversion to static methods. setC(setB(setA(b, 10), 20), 30); Flattening/SSA: t1 = setA(b, 10) t2 = setB(t1, 20) t3 = setC(t2, 30) After inlining: b.A = 10; t1 = b; t1.B = 20; t2 = t1 t2.C = 30 t3 = t2 After copy prop: b.A = 10 t1 = b b.B = 20 t2 = b b.C = 30 After dead code elimination: b.A = 10 b.B = 20 b.C = 30 On Tue, Jun 16, 2009 at 6:30 PM, Bruce Johnsonbr...@google.com wrote: Re: Wave access, I was really mostly just being playful, but I'll most certainly beg and plead to get this group early in the line if at all possible. Meanwhile, I agree with Cameron that we should make sure to discuss the major ideas here on the mailing list, even if some of the initial specifics are fleshed out in a wave. I definitely don't want people who don't yet have Wave accounts to feel penalized just because they weren't able to go to I/O. (But if you didn't go to I/O this year, I really hope you can next year -- it's fantastic to meet together in person.) On Tue, Jun 16, 2009 at 9:22 PM, Cameron Braid came...@braid.com.au wrote: Unfortunately I wasn't able to attend Google I/O, however I did watch a few of the sessions online. I signed up for the sandbox, but it appears that google aren't going to grant access to non IO attendees for a little while yet. I'd appreciate an invite, but I understand if that's not feasible. Cheers Cameron 2009/6/17 Ray Cromwell cromwell...@gmail.com Cameron, were you at Google I/O or did you sign up for the sandbox? I can ask a Googler to invite you if not. -Ray On Mon, Jun 15, 2009 at 6:21 PM, Cameron Braid came...@braid.com.au wrote: 2009/6/16 Bruce Johnson br...@google.com I'm starting to make a bit o' progress on this. I'll send out a design doc real soon
[gwt-contrib] Re: RR : Allow user-provided bridge classes in hosted mode
Glanced over it, but I'm sure it's fine so I didn't fine-tooth it. http://gwt-code-reviews.appspot.com/34836 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
