Refactor generating lazy deoptimization descriptors.

Refactor generating lazy deoptimization descriptors.

Instead of having special handling for closure calls, pass
the number of input operands down so that the correct lazy
deoptimization environment is generated at calls.

There is no functional change here - this is to simplify
having calls with pushed arguments and input operands
(like closure calls).

Runtime calls still do not have a correct lazy deoptimization environment
the environment should only be used for creating stack traces
from optimized code.

Fix a bug with --trace-deoptimization-verbose printing: We
cannot call ToCString on objects when the slots have not
been filled in yet. (e.g. Closures)

R=vegorov@google.com

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

[Florian Schneider, 2014-09-15 14:20:51]

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

[Vyacheslav Egorov (Google), 2014-09-15 14:35:56]

LGTM

https://codereview.chromium.org/575443002/diff/1/runtime/vm/deferred_objects.cc
File runtime/vm/deferred_objects.cc (right):

https://codereview.chromium.org/575443002/diff/1/runtime/vm/deferred_objects....
runtime/vm/deferred_objects.cc:95: cls.ToCString());
indicate that we are printing only class somehow [because object is not yet
completely filled] otherwise it would be confusing.

https://codereview.chromium.org/575443002/diff/1/runtime/vm/flow_graph_compil...
File runtime/vm/flow_graph_compiler_arm.cc (right):

https://codereview.chromium.org/575443002/diff/1/runtime/vm/flow_graph_compil...
runtime/vm/flow_graph_compiler_arm.cc:1126: RecordCallInfo(token_pos,
RawPcDescriptors::kOther, deopt_id, locs, 0);
this seems fragile that some of the call instructions just use
locs->input_count() and some don't (because it does not apply).

but it is not clear how clean this up.

[Florian Schneider, 2014-09-15 15:46:31]

https://codereview.chromium.org/575443002/diff/1/runtime/vm/deferred_objects.cc
File runtime/vm/deferred_objects.cc (right):

https://codereview.chromium.org/575443002/diff/1/runtime/vm/deferred_objects....
runtime/vm/deferred_objects.cc:95: cls.ToCString());
On 2014/09/15 14:35:56, Vyacheslav Egorov (Google) wrote:
> indicate that we are printing only class somehow [because object is not yet
> completely filled] otherwise it would be confusing.

Done.

https://codereview.chromium.org/575443002/diff/1/runtime/vm/flow_graph_compil...
File runtime/vm/flow_graph_compiler_arm.cc (right):

https://codereview.chromium.org/575443002/diff/1/runtime/vm/flow_graph_compil...
runtime/vm/flow_graph_compiler_arm.cc:1126: RecordCallInfo(token_pos,
RawPcDescriptors::kOther, deopt_id, locs, 0);
On 2014/09/15 14:35:56, Vyacheslav Egorov (Google) wrote:
> this seems fragile that some of the call instructions just use
> locs->input_count() and some don't (because it does not apply).
> 
> but it is not clear how clean this up.

I agree - the problem is that deoptimization environment at runtime calls is not
reflecting the unoptimized state. As a next step I'd really like to assert that
there is no lazy deoptimization at these runtime calls - or provide the correct
environment.

[Florian Schneider, 2014-09-16 10:32:03]

Committed patchset #3 (id:40001) manually as r40306 (presubmit successful).