Initialize the async jump variable with a smi to avoid polymorphic comparison.

Initialize the async jump variable with a smi to avoid polymorphic comparison.

Using the implicit initial null value makes the comparison in the dispatch
prologue of async closures polymorphic (Null|Smi). Initializing to it -1
eliminates the unnecessary class check for null.

Small clean up of scopes and internal variables used for async functions:
Capture them in the parser, so that there is no need to do this later in the
async-transformer.

R=hausner@google.com

Committed: https://code.google.com/p/dart/source/detail?r=41123

[Florian Schneider, 2014-10-14 14:39:56]

fschneider@google.com changed reviewers:
+ hausner@google.com

[Florian Schneider, 2014-10-14 14:39:57]

These are small unrelated things I noticed while debugging the optimized
async-closures.

[hausner, 2014-10-14 16:29:56]

LGTM with a comment.

https://codereview.chromium.org/655773003/diff/20001/runtime/vm/ast_transform...
File runtime/vm/ast_transformer.cc (left):

https://codereview.chromium.org/655773003/diff/20001/runtime/vm/ast_transform...
runtime/vm/ast_transformer.cc:145: GetVariableInScope(is_future_scope,
Symbols::AwaitJumpVar());
I am not sure why the lookup of these variables is here. But this lookup was
introduced by this CL

https://codereview.chromium.org//520223002

That fixed scope-related issues. Looking up the variable in this scope rather
than the top-level scope of the closure (as your change does) may have a subtle
desired side effect.

[Florian Schneider, 2014-10-15 11:40:59]

https://codereview.chromium.org/655773003/diff/20001/runtime/vm/ast_transform...
File runtime/vm/ast_transformer.cc (left):

https://codereview.chromium.org/655773003/diff/20001/runtime/vm/ast_transform...
runtime/vm/ast_transformer.cc:145: GetVariableInScope(is_future_scope,
Symbols::AwaitJumpVar());
On 2014/10/14 16:29:55, hausner wrote:
> I am not sure why the lookup of these variables is here. But this lookup was
> introduced by this CL
> 
> https://codereview.chromium.org//520223002
> 
> That fixed scope-related issues. Looking up the variable in this scope rather
> than the top-level scope of the closure (as your change does) may have a
subtle
> desired side effect.
> 

Here the side effect occurs twice (here and again when looking up the same
variables in the EffectGraphVisitr::VisitAwaitMarkerNode). Maybe the code
changed so that this became redundant.

[Florian Schneider, 2014-10-15 11:41:27]

Committed patchset #2 (id:20001) manually as r41123 (presubmit successful).