In optimized code use IC calls for instance calls that have no IC data instead of deoptimizing. The…

In optimized code use IC calls for instance calls that have no IC data instead of deoptimizing. The optimized IC call increments usage counter and reoptimizes optimized function if the threshold is met.

Recognize closure calls and mark them in ICData. Closure calls do not populate ICData, i.e., number of checks is always 0 (unless mixed closure calls with regular instance calls). Therefore closure IC calls do not count for reoptimization.
Committed: https://code.google.com/p/dart/source/detail?r=14860

[Kevin Millikin (Google), 2012-11-13 17:56:53]

LGTM with some small comments.

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/code_generator.cc
File runtime/vm/code_generator.cc (right):

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/code_generator...
runtime/vm/code_generator.cc:1492: reinterpret_cast<uword>(ic_data.raw()),
You don't have to cast the pointer to uword and use format specifier %Px.  You
can just leave it as a pointer and use %p.

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/flow_graph_com...
File runtime/vm/flow_graph_compiler_ia32.cc (right):

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/flow_graph_com...
runtime/vm/flow_graph_compiler_ia32.cc:1053: // Load top function since it may
not correspond to the ICData function.
Expand this comment to include why it can be different, with an example, so we
can remember why we did it this way.

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/intermediate_l...
File runtime/vm/intermediate_language_ia32.cc (right):

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/intermediate_l...
runtime/vm/intermediate_language_ia32.cc:64: compiler->GenerateCall(0,  // no
token position.
I always have to figure out why we optimize at return instead of entry.  Let's
put a comment here (unless you can think of somewhere better) explaining the
reasons in case we want to revisit the design later.

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/object.h
File runtime/vm/object.h (right):

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/object.h#newco...
runtime/vm/object.h:2803: return raw_ptr()->is_closure_call_  == 1;
There's an extra space before ==.

[srdjan, 2012-11-13 18:21:38]

Thanks!

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/code_generator.cc
File runtime/vm/code_generator.cc (right):

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/code_generator...
runtime/vm/code_generator.cc:1492: reinterpret_cast<uword>(ic_data.raw()),
On 2012/11/13 17:56:53, kmillikin wrote:
> You don't have to cast the pointer to uword and use format specifier %Px.  You
> can just leave it as a pointer and use %p.

Done.

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/flow_graph_com...
File runtime/vm/flow_graph_compiler_ia32.cc (right):

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/flow_graph_com...
runtime/vm/flow_graph_compiler_ia32.cc:1053: // Load top function since it may
not correspond to the ICData function.
On 2012/11/13 17:56:53, kmillikin wrote:
> Expand this comment to include why it can be different, with an example, so we
> can remember why we did it this way.

Done:

  // Each ICData propagated from unoptimized to optimized code contains the
  // function that corresponds to the Dart function of that IC call. Due
  // to inlining in optimized code, that function may not correspond to the
  // top-level function (parsed_function().function()) which could be
  // reoptimized and which counter needs to be incremented.
  // Pass the function explicitly.

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/intermediate_l...
File runtime/vm/intermediate_language_ia32.cc (right):

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/intermediate_l...
runtime/vm/intermediate_language_ia32.cc:64: compiler->GenerateCall(0,  // no
token position.
On 2012/11/13 17:56:53, kmillikin wrote:
> I always have to figure out why we optimize at return instead of entry.  Let's
> put a comment here (unless you can think of somewhere better) explaining the
> reasons in case we want to revisit the design later.

Done:
// Attempt optimized compilation at return instruction instead of at the entry.
// The entry needs to be patchable, no inlined objects are allowed in the area
// that will be overwritten by the patch instruction: a jump).

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/object.h
File runtime/vm/object.h (right):

https://codereview.chromium.org/11361225/diff/13005/runtime/vm/object.h#newco...
runtime/vm/object.h:2803: return raw_ptr()->is_closure_call_  == 1;
On 2012/11/13 17:56:53, kmillikin wrote:
> There's an extra space before ==.

Done.