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
Correct me if I'm wrong, but isn't the closure collections library more like
JRE-ish collections than simple JSO wrappers? My impression of most JS code
was that if it needed a string map or simple array, people tended to just
use raw objects, knowing that there are certain strange behaviors they
For those interested, I put up the optimization article on the wiki instead
of Wave, see it here:
http://code.google.com/p/google-web-toolkit/wiki/AdvancedCompilerOptimizations
It surveys and documents some potentially promising areas to look at. My
suspicion is that a lot of Java idioms:
Stefan, It'll be atleast until the end of the week as my plate is full
doing lots of stuff. Also, I'd like to see what Bruce's proposal is before
I go off and do too much.
-Ray
On Wed, Jun 17, 2009 at 3:37 PM, Stefan Haustein haust...@google.comwrote:
On Tue, Jun 16, 2009 at 12:54 AM,
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
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
I think we're doing pretty well overall with global/interprocedural stuff
(type tightening, param + field pruning, etc.). Where we haven't done much,
ironically, is the textbook intraprocedural stuff. Fortunately, the latter
is the very stuff that's most amenable to the hybrid (and, notably,
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
On Wed, Jun 17, 2009 at 1:16 PM, Ray Cromwell cromwell...@gmail.com wrote:
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
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?
E.g.
public List getList(int x) {
if(x 10) {
return new LinkedList();
}
else {
return new ArrayList();
}
}
List list =
On Wed, Jun 17, 2009 at 3:01 PM, Ray Cromwell cromwell...@gmail.com 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
On Tue, Jun 16, 2009 at 12:54 AM, Stefan Haustein haust...@google.comwrote:
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.
Ray,
I am blocking on this for other size
Stefan, if it's really urgent, I would suggest just forking JsArray into
your own project packages for a while. They're simple enough that it won't
be much trouble to unfork when something better comes along -- the
collections I have in mind for core GWT are a little more ambitious, and so
they
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
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
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
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.
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
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
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.comwrote:
Ray,
I
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,
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
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
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
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
+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
On Thu, Jun 11, 2009 at 7:51 AM, 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
On 11 juin, 16:11, John Tamplin j...@google.com wrote:
On Thu, Jun 11, 2009 at 7:51 AM, 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
On Thu, Jun 11, 2009 at 3:42 PM, Thomas Broyer t.bro...@gmail.com wrote:
On 11 juin, 16:11, John Tamplin j...@google.com wrote:
On Thu, Jun 11, 2009 at 7:51 AM, Joel Webber j...@google.com wrote:
+1 Ray. Now here's the really tricky question. Is there any way we can
take
advantage of
On Thu, Jun 11, 2009 at 10:42 AM, Thomas Broyer t.bro...@gmail.com wrote:
On 11 juin, 16:11, John Tamplin j...@google.com wrote:
On Thu, Jun 11, 2009 at 7:51 AM, Joel Webber j...@google.com wrote:
+1 Ray. Now here's the really tricky question. Is there any way we can
take
advantage of
On Tue, Jun 9, 2009 at 11:03 AM, Stefan Hausteinhaust...@google.com wrote:
On Tue, Jun 9, 2009 at 3:50 PM, Lex Spoon sp...@google.com wrote:
On Mon, Jun 8, 2009 at 7:22 PM, Bruce Johnsonbr...@google.com wrote:
Please also look at the compiled JS. I think the less restrictive bound
will
Bah, mis-send. What I was typing was:
I though the point was to get rid of JRE collections? Anyway, the
collection in question is used as a queue. I would hate to see its
performance get worse when there'
...when there's a known, straightforward alternative, and when that
alternative
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 to T if it doesn't effect performance cause
then I could subclass it, but as an example of the stuff I would like
in a 'FastArrayList'
On Tue, Jun 9, 2009 at 1:02 AM, Ray Cromwell cromwell...@gmail.com wrote:
In particular, I use my own JsArray/JsMap implementation to avoid JRE
collections in GQuery. Perhaps rather than patching JsArray, there
should just be something like FastArrayList and FastMap which do not
implement
On Mon, Jun 8, 2009 at 7:22 PM, Bruce Johnsonbr...@google.com wrote:
Please also look at the compiled JS. I think the less restrictive bound will
cause the compiler to generate worse code (e.g. dynamic casts in some or all
contexts) which would make it a non-starter.
Okay, the law has been
On Tue, Jun 9, 2009 at 3:50 PM, Lex Spoon sp...@google.com wrote:
On Mon, Jun 8, 2009 at 7:22 PM, Bruce Johnsonbr...@google.com wrote:
Please also look at the compiled JS. I think the less restrictive bound
will
cause the compiler to generate worse code (e.g. dynamic casts in some or
all
Wouldn't this break existing code, such as?
JsArray noGenericParams = ;
SomeJso jso = noGenericParams.get(i).cast();
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Mon, Jun 8, 2009 at 6:22 PM, Stefan Haustein haust...@google.com wrote:
I'd like to submit a patch (see below) that changes JsArrayT extends
JavaScriptObject to JsArrayT
Motivation:
Support more lightweight code in places where we depend on Javascript
anyway.
In particular, I would
Please also look at the compiled JS. I think the less restrictive bound will
cause the compiler to generate worse code (e.g. dynamic casts in some or all
contexts) which would make it a non-starter.
On Mon, Jun 8, 2009 at 6:22 PM, Stefan Haustein haust...@google.com wrote:
Hi,
I'd like to
In particular, I use my own JsArray/JsMap implementation to avoid JRE
collections in GQuery. Perhaps rather than patching JsArray, there
should just be something like FastArrayList and FastMap which do not
implement JRE Collections, but are nothing more than wrappers around
JS arrays and objects
What you describe, Ray, is definitely going to happen. It has to. I have
begun a design doc for that very thing. I'll float it for comments as soon
as I'm finished with the first draft.
On Mon, Jun 8, 2009 at 8:02 PM, Ray Cromwell cromwell...@gmail.com wrote:
In particular, I use my own
41 matches
Mail list logo
