[gwt-contrib] Re: fixes runAsync initial load sequences and adds a test case
The fix looks good, but I don't think that any tests beyond the first
are validating that the load sequence is working correctly.
http://gwt-code-reviews.appspot.com/43802/diff/1/4
File user/test/com/google/gwt/dev/jjs/InitialLoadSequence.gwt.xml
(right):
http://gwt-code-reviews.appspot.com/43802/diff/1/4#newcode2
Line 2:
2009
http://gwt-code-reviews.appspot.com/43802/diff/1/3
File user/test/com/google/gwt/dev/jjs/test/InitialLoadSequenceTest.java
(right):
http://gwt-code-reviews.appspot.com/43802/diff/1/3#newcode45
Line 45: public void testInOrder() {
Unless the app is re-loaded, will any tests other than the first
actually verify that the loading sequence is behaving as desired?
http://gwt-code-reviews.appspot.com/43802
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Changing JsArray to JsArray
On Wed, Jun 17, 2009 at 7:33 PM, Stefan Haustein wrote: > Our main problem is code size, so "ambitious" scares me :) > I'm glad to hear it -- your paranoia stems from dedication to a creating great user experience. That's an A+ reaction in my book :-) The bottom describes why it's "ambitious" in a bit more detail. The actual problem at hand is that GWT runasync stuff drags in LinkedList > which is used nowhere else, so having our own copy of JsArray in our project > won't really help (And my CL for replacing Hashtable with our own > JsStringMap slowly deteriorates because I realized that Hashtable is used in > GWT internally in libraries we cannot replace easily). > Yes, we need to replace those uses as soon as we can. I really hope the new collections can be ready really soon, but even if not, we can do temporary lighter-weight collections so that you can escape JRE collections. > Why not release early and start with a basic copy of JsArray and then add > more functionality (e.g. iterable) later? > Collections are very, very amenable to bikeshedding, so I want to have a pretty well thought-out plan so as to avoid endless "what if" threads, if at all possible. Of course, if the design is bad, people will hopefully say so and we'll do something different. But I just don't want to start with so little that it doesn't have enough intertia to achieve escape velocity. When I say "ambitious" I mean that it's ambitious in its design goals, not in its implementation. The key thing we need to do is make the collection attractive enough that people will feel comfortable using them on the server side, too. This is important because otherwise, they'll use JRE collections in RPC, which will mean the client-side code will be *worse*, because it will probably have both sets of collections and still more code to convert from JRE collections to GWT collections, and so on. A related set of design goals is to have rich enough type hierarchy that people can feel very confident avoiding defensive code. Patterns like "clone collections if you're not sure they're not aliased by someone else" are death in JS, as I'm sure you know well. We need collections that can express concepts like immutability statically, so that developers will simply know that there's no need to defensively clone them. Stuff like that: smarter choice of types so as to require *less* code in the client, and make 'em more optimizable, too. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Misc JS problem cleanup
Reviewers: jgw,
Description:
A few miscellaneous fixes for JS issues. We might also want to merge
into releases/1.6.
Please review this at http://gwt-code-reviews.appspot.com/42802
Affected files:
user/src/com/google/gwt/dom/client/OptionElement.java
user/src/com/google/gwt/dom/client/TableSectionElement.java
user/src/com/google/gwt/user/client/ui/PrefixTree.java
Index: user/src/com/google/gwt/dom/client/OptionElement.java
--- user/src/com/google/gwt/dom/client/OptionElement.java (revision 5396)
+++ user/src/com/google/gwt/dom/client/OptionElement.java (working copy)
@@ -42,7 +42,7 @@ public class OptionElement extends Element {
* control is not within the context of a form.
*/
public final native FormElement getForm() /*-{
-return form;
+return this.form;
}-*/;
/**
Index: user/src/com/google/gwt/dom/client/TableSectionElement.java
--- user/src/com/google/gwt/dom/client/TableSectionElement.java (revision
3193)
+++ user/src/com/google/gwt/dom/client/TableSectionElement.java (working
copy)
@@ -92,7 +92,7 @@ public class TableSectionElement extends Element {
* HTMLTheadElement for details.
*/
public final native String getVAlign() /*-{
-return this.valign;
+return this.vAlign;
}-*/;
/**
@@ -140,6 +140,6 @@ public class TableSectionElement extends Element {
* HTMLTheadElement for details.
*/
public final native void setVAlign(String vAlign) /*-{
-this.valign = valign;
+this.vAlign = vAlign;
}-*/;
}
Index: user/src/com/google/gwt/user/client/ui/PrefixTree.java
--- user/src/com/google/gwt/user/client/ui/PrefixTree.java (revision 2332)
+++ user/src/com/google/gwt/user/client/ui/PrefixTree.java (working copy)
@@ -41,6 +41,8 @@ class PrefixTree extends AbstractCollection {
*/
private static class PrefixTreeIterator implements Iterator {
+@SuppressWarnings("unused")
+// Called from JSNI.
private JavaScriptObject stack;
/**
@@ -99,7 +101,7 @@ class PrefixTree extends AbstractCollection {
*/
private native void addTree(PrefixTree tree, String prefix) /*-{
var suffixes = [];
- for (suffix in
tr...@com.google.gwt.user.client.ui.prefixtree::suffixes) {
+ for (var suffix in
tr...@com.google.gwt.user.client.ui.prefixtree::suffixes) {
suffixes.push(suffix);
}
@@ -162,7 +164,7 @@ class PrefixTree extends AbstractCollection {
// Put all subframes on the stack, and return to top of loop.
} else {
- for (key in frame.subtrees) {
+ for (var key in frame.subtrees) {
var target = frame.prefix + unsafe(key);
var subtree = frame.subtrees[key];
@@ -411,7 +413,7 @@ class PrefixTree extends AbstractCollection {
// The answer can only exist in this tree's suffixes or subtree keys.
} else {
// Check local suffixes.
- for (suffix in suffixes) {
+ for (var suffix in suffixes) {
var target = prefix +
@com.google.gwt.user.client.ui.PrefixTree::unsafe(Ljava/lang/String;)(suffix);
if (target.indexOf(search) == 0) {
outp...@java.util.collection::add(Ljava/lang/Object;)(target);
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] fixes runAsync initial load sequences and adds a test case
Reviewers: bobv, Description: In trunk, the use of an initial load sequence is currently broken. This patch has the one-line fix, and adds a test case of initial load sequences. Please review this at http://gwt-code-reviews.appspot.com/43802 Affected files: dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java user/test/com/google/gwt/dev/jjs/CompilerSuite.java user/test/com/google/gwt/dev/jjs/InitialLoadSequence.gwt.xml user/test/com/google/gwt/dev/jjs/test/InitialLoadSequenceTest.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Patch for incubator issue #271
Thanks. Committed as r1682 in incubator.
On Thu, Jun 18, 2009 at 4:47 PM, John LaBanca wrote:
> LGTM. I'll update this tomorrow.
>
> Thanks,
> John LaBanca
> jlaba...@google.com
>
>
>
> On Thu, Jun 18, 2009 at 4:30 PM, Isaac Truett wrote:
>
>> Hi John,
>>
>> I know that PagingScrollTable is headed for trunk already, but I thought
>> we could slip this small patch into the incubator for the mean time. Would
>> you mind giving it a quick review?
>>
>> Thanks,
>> Isaac
>>
>>
>> Index: src/com/google/gwt/widgetideas/table/client/PagingOptions.java
>> ===
>> --- src/com/google/gwt/widgetideas/table/client/PagingOptions.java (revision
>> 1681)
>> +++ src/com/google/gwt/widgetideas/table/client/PagingOptions.java (working
>> copy)
>> @@ -173,7 +173,7 @@
>> numPagesLabel = new HTML();
>>
>> // Create the loading image
>> -loadingImage = new Image("scrollTableLoading.gif");
>> +loadingImage = new Image(GWT.getModuleBaseURL() +
>> "scrollTableLoading.gif");
>> loadingImage.setVisible(false);
>>
>> // Create the error label
>> Index: src/com/google/gwt/gen2/table/client/PagingOptions.java
>> ===
>> --- src/com/google/gwt/gen2/table/client/PagingOptions.java (revision
>> 1681)
>> +++ src/com/google/gwt/gen2/table/client/PagingOptions.java (working
>> copy)
>> @@ -182,7 +182,7 @@
>> numPagesLabel = new HTML();
>>
>> // Create the loading image
>> -loadingImage = new Image("scrollTableLoading.gif");
>> +loadingImage = new Image(GWT.getModuleBaseURL() +
>> "scrollTableLoading.gif");
>> loadingImage.setVisible(false);
>>
>> // Create the error label
>>
>>
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Patch for incubator issue #271
LGTM. I'll update this tomorrow.
Thanks,
John LaBanca
jlaba...@google.com
On Thu, Jun 18, 2009 at 4:30 PM, Isaac Truett wrote:
> Hi John,
>
> I know that PagingScrollTable is headed for trunk already, but I thought we
> could slip this small patch into the incubator for the mean time. Would you
> mind giving it a quick review?
>
> Thanks,
> Isaac
>
>
> Index: src/com/google/gwt/widgetideas/table/client/PagingOptions.java
> ===
> --- src/com/google/gwt/widgetideas/table/client/PagingOptions.java (revision
> 1681)
> +++ src/com/google/gwt/widgetideas/table/client/PagingOptions.java (working
> copy)
> @@ -173,7 +173,7 @@
> numPagesLabel = new HTML();
>
> // Create the loading image
> -loadingImage = new Image("scrollTableLoading.gif");
> +loadingImage = new Image(GWT.getModuleBaseURL() +
> "scrollTableLoading.gif");
> loadingImage.setVisible(false);
>
> // Create the error label
> Index: src/com/google/gwt/gen2/table/client/PagingOptions.java
> ===
> --- src/com/google/gwt/gen2/table/client/PagingOptions.java (revision
> 1681)
> +++ src/com/google/gwt/gen2/table/client/PagingOptions.java (working copy)
> @@ -182,7 +182,7 @@
> numPagesLabel = new HTML();
>
> // Create the loading image
> -loadingImage = new Image("scrollTableLoading.gif");
> +loadingImage = new Image(GWT.getModuleBaseURL() +
> "scrollTableLoading.gif");
> loadingImage.setVisible(false);
>
> // Create the error label
>
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Patch for incubator issue #271
Hi John,
I know that PagingScrollTable is headed for trunk already, but I thought we
could slip this small patch into the incubator for the mean time. Would you
mind giving it a quick review?
Thanks,
Isaac
Index: src/com/google/gwt/widgetideas/table/client/PagingOptions.java
===
--- src/com/google/gwt/widgetideas/table/client/PagingOptions.java (revision
1681)
+++ src/com/google/gwt/widgetideas/table/client/PagingOptions.java (working
copy)
@@ -173,7 +173,7 @@
numPagesLabel = new HTML();
// Create the loading image
-loadingImage = new Image("scrollTableLoading.gif");
+loadingImage = new Image(GWT.getModuleBaseURL() +
"scrollTableLoading.gif");
loadingImage.setVisible(false);
// Create the error label
Index: src/com/google/gwt/gen2/table/client/PagingOptions.java
===
--- src/com/google/gwt/gen2/table/client/PagingOptions.java (revision 1681)
+++ src/com/google/gwt/gen2/table/client/PagingOptions.java (working copy)
@@ -182,7 +182,7 @@
numPagesLabel = new HTML();
// Create the loading image
-loadingImage = new Image("scrollTableLoading.gif");
+loadingImage = new Image(GWT.getModuleBaseURL() +
"scrollTableLoading.gif");
loadingImage.setVisible(false);
// Create the error label
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5588 - Add an escape hatch to CompilingClassLoader to allow individual "client" classes to be lo...
Author: b...@google.com
Date: Thu Jun 18 08:58:28 2009
New Revision: 5588
Added:
trunk/dev/core/src/com/google/gwt/dev/shell/rewrite/HasAnnotation.java
trunk/dev/core/super/com/google/gwt/core/client/GwtScriptOnly.java
- copied, changed from r5585,
/trunk/user/src/com/google/gwt/dom/client/TagName.java
trunk/user/test-super/
trunk/user/test-super/com/
trunk/user/test-super/com/google/
trunk/user/test-super/com/google/gwt/
trunk/user/test-super/com/google/gwt/dev/
trunk/user/test-super/com/google/gwt/dev/jjs/
trunk/user/test-super/com/google/gwt/dev/jjs/super/
trunk/user/test-super/com/google/gwt/dev/jjs/super/com/
trunk/user/test-super/com/google/gwt/dev/jjs/super/com/google/
trunk/user/test-super/com/google/gwt/dev/jjs/super/com/google/gwt/
trunk/user/test-super/com/google/gwt/dev/jjs/super/com/google/gwt/dev/
trunk/user/test-super/com/google/gwt/dev/jjs/super/com/google/gwt/dev/jjs/
trunk/user/test-super/com/google/gwt/dev/jjs/super/com/google/gwt/dev/jjs/scriptonly/
trunk/user/test-super/com/google/gwt/dev/jjs/super/com/google/gwt/dev/jjs/scriptonly/ScriptOnlyClass.java
trunk/user/test/com/google/gwt/dev/jjs/ScriptOnlyTest.gwt.xml
- copied, changed from r5585,
/trunk/user/src/com/google/gwt/jsonp/Jsonp.gwt.xml
trunk/user/test/com/google/gwt/dev/jjs/scriptonly/
trunk/user/test/com/google/gwt/dev/jjs/scriptonly/BaseClass.java
- copied, changed from r5585,
/trunk/user/test/com/google/gwt/dev/jjs/test/singlejso/IB.java
trunk/user/test/com/google/gwt/dev/jjs/scriptonly/ScriptOnlyClass.java
trunk/user/test/com/google/gwt/dev/jjs/scriptonly/ScriptOnlyTest.java
trunk/user/test/com/google/gwt/dev/jjs/server/
trunk/user/test/com/google/gwt/dev/jjs/server/AccessedByScriptOnlyClass.java
- copied, changed from r5585,
/trunk/user/test/com/google/gwt/dev/jjs/test/singlejso/B2.java
Modified:
trunk/dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
trunk/user/build.xml
trunk/user/test/com/google/gwt/dev/jjs/CompilerSuite.java
Log:
Add an escape hatch to CompilingClassLoader to allow individual "client"
classes to be loaded from bytecode on the classpath and escape the module's
source path jail.
Patch by: bobv
Review by: scottb
Modified:
trunk/dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
==
--- trunk/dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
(original)
+++ trunk/dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
Thu Jun 18 08:58:28 2009
@@ -16,6 +16,7 @@
package com.google.gwt.dev.shell;
import com.google.gwt.core.client.GWTBridge;
+import com.google.gwt.core.client.GwtScriptOnly;
import com.google.gwt.core.ext.TreeLogger;
import com.google.gwt.core.ext.UnableToCompleteException;
import com.google.gwt.core.ext.TreeLogger.Type;
@@ -31,9 +32,11 @@
import com.google.gwt.dev.javac.CompiledClass;
import com.google.gwt.dev.javac.JsniMethod;
import com.google.gwt.dev.jjs.InternalCompilerException;
+import com.google.gwt.dev.shell.rewrite.HasAnnotation;
import com.google.gwt.dev.shell.rewrite.HostedModeClassRewriter;
import
com.google.gwt.dev.shell.rewrite.HostedModeClassRewriter.InstanceMethodOracle;
import com.google.gwt.dev.util.JsniRef;
+import com.google.gwt.dev.util.Util;
import com.google.gwt.util.tools.Utility;
import org.apache.commons.collections.map.AbstractReferenceMap;
@@ -323,6 +326,31 @@
}
/**
+ * A ClassLoader that will delegate to a parent ClassLoader and fall
back to
+ * loading bytecode as resources from an alternate parent ClassLoader.
+ */
+ private static class MultiParentClassLoader extends ClassLoader {
+private final ClassLoader resources;
+
+public MultiParentClassLoader(ClassLoader parent, ClassLoader
resources) {
+ super(parent);
+ this.resources = resources;
+}
+
+@Override
+protected synchronized Class findClass(String name)
+throws ClassNotFoundException {
+ String resourceName = name.replace('.', '/') + ".class";
+ URL url = resources.getResource(resourceName);
+ if (url == null) {
+throw new ClassNotFoundException();
+ }
+ byte[] bytes = Util.readURLAsBytes(url);
+ return defineClass(name, bytes, 0, bytes.length);
+}
+ }
+
+ /**
* Implements {...@link InstanceMethodOracle} on behalf of the
* {...@link HostedModeClassRewriter}. Implemented using {...@link
TypeOracle}.
*/
@@ -574,9 +602,14 @@
private final TreeLogger logger;
+ private final Set scriptOnlyClasses = new HashSet();
+
+ private ClassLoader scriptOnlyClassLoader;
+
private ShellJavaScriptHost shellJavaScriptHost;
private final Set singleJsoImplTypes = new HashSet();
+
/**
* Used by {...@link #findClass(String)} to prevent reentrant JSNI
injection.
[gwt-contrib] Re: Changing JsArray to JsArray
This sounds like a very reasonable approach. Pruning clinits based on the
whole program CFG is definitely interesting, but is there an estimate on the
saving (speed/size) that would be gained from that optimization? I ask,
just as a cross-check.
On Wed, Jun 17, 2009 at 1:16 PM, Ray Cromwell wrote:
>
> Miguel, for what it's worth, I agree wholeheartedly. Object oriented
> programming tends to encourage small block sizes except where inlining helps
> to enlarge them, so inter-block definitely helps alot. Moreover, you can't
> really build a good CFA/DFA without inter-block information propagation.
> Here's an off the cuff proposal for doing this later:
>
> Step 1, as I outlined, is to take JExpressions which are not literals,
> fieldrefs, etc and introduce temporaries so as to introduce a three-address
> style into the AST.
> e.g.
> a + b where a is unary/binary/etc op becomes t = a, t + b
> return expr becomes t=expr; return t
> while(expr) becomes t=expr, while(t) { t=expr; }
> etc
>
> This gives us an AST structure amenable to traditional analysis without
> introducing a totally new IR, we can reuse most of the existing JNode
> classes, only unlike what you'd find in the Dragon Book, we keep high level
> ops for loops, conditionals, method calls, and everything else.
>
> Step 2, introduce a new JPhi node (extends JNode). Build CFG. Add steps to
> compute dominator trees/dominance frontiers and use these to insert JPhi
> nodes into the ASTs. Modify all of the existing visitors to deal with JPhi.
> Add stage to unSSA.
>
> Step 3: Introduce optimizations to this structure. Edge-split form. Faster
> 'optimal' dominance algorithms (I say, use something simpler like the Cooper
> technique at first:
> http://www.hipersoft.rice.edu/grads/publications/dom14.pdf)
>
> The crucial question is whether to do procedure level CFG, or whole program
> CFG. One of the things that interested me about the potential of building a
> limited whole-program CFG was the ability to aggressively (and correctly)
> prune clinits. Now, if the eager clinit hoisting is acceptable, than this
> would be overkill, but if not, then the way to do it is to compute the
> immediate dominator hierarchy for each block.
>
> If block B_j contains clinitA() and it is dominated by some block B_i in
> its immediate dominators which contains a call to clinitA(), then it is safe
> to remove clinitA() from B_j since all possible paths of execution for
> reaching B_j must first go through B_i, guaranteeing the clinitA() would
> have been invoked.
>
> -Ray
>
> 2009/6/17 Miguel Méndez
>
>> If you are going to tackle the intra-block optimization, you might as well
>> for inter-block opt with block summaries that merge across the control flow.
>> The later is not that much harder since you summarize the intra-block data
>> and propagate. But yes, doing SSA for real is a non-trivial amount of work.
>>
>>
>> On Wed, Jun 17, 2009 at 11:44 AM, Ray Cromwell wrote:
>>
>>>
>>> I agree. My current proposal really isn't SSA, but poor man's SSA, which
>>> is to simply flatten blocks by introducing temporaries, renumber the
>>> existing variables, perform classic intra-block optimizations, and then
>>> undo. This would atleast result in some modest block level improvements,
>>> including making builder pattern more optimal. The in-block renumbering
>>> procedure I've come up with essentially constructs the liveness range
>>> information as your doing it, without having to deal with the more exotic
>>> SSA algorithms. It might be small enough to perform a useful experiment
>>> without too much work.
>>> Doing real SSA would require quite a bit more work, especially if you
>>> want to deal fully with exceptions and arrays. That to me is something
>>> that's too big of a change to the current compiler infrastructure at the
>>> moment.
>>>
>>> -Ray
>>>
>>>
>>> 2009/6/17 Miguel Méndez
>>>
Longer term moving towards an SSA variant has a lot of
advantages. In the near term, simply experimenting with performing the
classic intra-procedural (block global) optimizations wouldn't necessarily
require SSA although SSA does make the bookkeeping easier and faster. If
you introduced a pass to perform the intra-procedural optimizations that
would not violate the invariants expected by subsequent optimizations
(procedure is still in tree form) you'd go a long way.
If you do go with SSA, it's my experience that you should go all the way
and dead create deal with the phi functions otherwise you end up getting a
lot more temps than you would otherwise and therefore more "live" refs etc.
On Wed, Jun 17, 2009 at 1:12 AM, Ray Cromwell wrote:
>
> 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 gener
[gwt-contrib] Re: Changing JsArray to JsArray
I've seen c/c++ compilers do this type of thing, but it usually plays out
via escape/side-effect analysis/inlining which is not exactly a T'-type
approach but ends up having the same type of effect. The b's lifetime is
restrictricted to the foo() method because no reference to b escapes
it. With that in place, you can propagate the effects on b across the method's
statements which should allow you to conclude that b.elems is null across
the body thereby allowing you to drop the the iterations. If the
constructor itself has no side-effects, then you can remove the object
allocation all together. You could extend the technique to deal with
situations where references to b does escape.
On Wed, Jun 17, 2009 at 6:07 PM, Bruce Johnson wrote:
> On Wed, Jun 17, 2009 at 3:01 PM, Ray Cromwell wrote:
>
>> Bruce, By type cloning, do you mean using typeflow information to
>> compute a set of types for a given reference, and then speculatively type
>> tightening?
>>
>
> I'm talking about something else, but you're right about the Will explain
> more in the bottom section.
>
>
>>
>> We can compute the set of potential concrete types for 'list' as
>> {LinkedList, ArrayList}. Therefore, we can inline the call to list.get(n),
>> as:
>>
>
> This is what Scott and Lex have been calling something like, "set-base type
> tightening".
>
> If someNonInlineableMethod() is only ever reached from blocks where the
>> parameter is ArrayList, then the 'l' parameter can be tightened to
>> ArrayList. You need CFG/flow analysis because methodA(List l) might call
>> methodB(List l) where the chain is only ever invoked with ArrayList.
>>
>
> We do a CFG-independent version of what you're talking about. We do tighten
> parameter types, but only based on the (tightened) types of all the call
> sites, without regard to control flow.
>
> === Type Cloning ===
> What I mean by type cloning is this: for every unique (lexical) occurrence
> of an allocation of type T, clone T into T' as if it were an independent
> type, but arrange that T' is indistinguishable from T w.r.t. casts,
> instanceof, and getClass(). In other words, you could never determine at
> runtime that the object wasn't actually a genuine T. Now, optimize as
> normal. To see how this could play out:
>
> class BasicList {
>
> private E[] elems;
>
>
> @SuppressWarnings("unchecked")
>
> public void add(E elem) {
>
> if (elems == null) {
>
> elems = (E[]) new Object[] {elem};
>
> } else {
>
> E[] newElems = (E[]) new Object[elems.length + 1];
>
> System.arraycopy(elems, 0, newElems, 0, elems.length);
>
> newElems[newElems.length - 1] = elem;
>
> elems = newElems;
>
> }
>
> }
>
>
> public int size() {
>
> return elems == null ? 0 : elems.length;
>
> }
>
>
>
> public Iterator iterator() {
>
> final int n = size();
>
>
> return new Iterator() {
>
> private final int i = 0;
>
>
> public boolean hasNext() {
>
> return i < n;
>
> }
>
>
> public E next() {
>
> return elems[i];
>
> }
>
>
> public void remove() {
>
> // nothing
>
> }
>
> };
>
> }
>
> }
>
> // Then in some other code, you could write...
> void foo() {
> BasicList b = new BasicList();
> for (int i = 0, n = b.size(); i < n; ++i) {
> // Removed by dead code elim.
> }
>
> for (String s: b) {
> // Also removed by dead code elim.
> }
> }
>
> In the above, b is of type BasicList' (a clone of BasicList that can be
> independently optimized). Thus, you can see that BasicList' does not have
> the add() method called, which means that, for this particular use of the
> type, the 'elems' field will always be null. Consequently, size() can be
> statically known to return 0. Similarly, the iterator's hasNext() method can
> be statically shown to always return false in the for/each loop.
>
> The key point is that the usage of a type in one context would not affect
> how the type itself could be optimized in other contexts. As it stands
> today, we can't do the above optimization if anywhere in the program someone
> calls BasicList#add(). A great practical example is Widgets firing events.
> You want widgets to be *able* to fire events *if* someone actually wants to
> listen to them. In the cases where you can see that there are no listeners
> to a widget, you'd really like the entirely of the even-firing infrastructur
> to completely disappear. So, I think it can be a big win.
>
>
>
>
> >
>
--
Miguel
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Comment on RpcDirectEval in google-web-toolkit
Just digging into the derpc code. Wouah. This is a huge evolution compared to the previous RPC model - CommandSink - Serialization extension point - CFS retired - Connection between gwtc and serialization model for optimization (via GWT.isReachable()) - clientOracle class, etc ... - new linker to generate *.gwt.rpc2 don't get much time to read all, but the code sounds really more complex than the design doc would suggest ... Bob, will you provide more explanation/docs on rpc2, specifically in terms of compatibility with the existing rpc ? I think the name "Direct Eval" is not really appropriate since it is really about a kind of rpc v2 Sami On Thu, Jun 18, 2009 at 9:03 AM, BobV wrote: > > On Wed, Jun 17, 2009 at 10:38 PM, wrote: > > Has this/is this going anywhere? Has actual work been done on the > > implementation? > > Glad you asked: > > http://google-web-toolkit.googlecode.com/svn/changes/bobv/derpc/ > > I'm working on getting the initial version merged into trunk to get > more exposure for it. > > -- > Bob Vawter > Google Web Toolkit Team > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Comment on RpcDirectEval in google-web-toolkit
On Wed, Jun 17, 2009 at 10:38 PM, wrote: > Has this/is this going anywhere? Has actual work been done on the > implementation? Glad you asked: http://google-web-toolkit.googlecode.com/svn/changes/bobv/derpc/ I'm working on getting the initial version merged into trunk to get more exposure for it. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
