Fixes bug where we would occasionally materialize a corrupted object.

Fixes bug where we would occasionally materialize a corrupted object.

On the slow path for a stack overflow check we manually spill the live
registers before our call to the runtime function.  We were updating
all uses of these spilled registers in the Environment object but this
was not enough - we also need to update any uses of these spilled
registers in MaterializeObjectInstrs which are hanging off of the
Environment.

This would fail when a deoptimization was triggered during a stack
overflow check and a materialized object happened to refer to
registers.

I've been chasing this for a while and I was able to get it to
reliably reproduce by using the --stacktrace_every=N and the
--stacktrace_filter flags, which were added for this purpose.

ALSO:

Set the top context to null on exceptions/errors.  This is needed for
the --verify-incoming-context flag.

Minor printing improvements.

R=fschneider@google.com

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

[turnidge, 2014-04-22 17:10:38]

Florian please take a look at this change.  It fixes a problem in deoptimization
that has been showing up while using the Observatory.

[Florian Schneider, 2014-04-25 05:55:32]

Lgtm.

https://codereview.chromium.org/246303004/diff/10001/runtime/vm/intermediate_...
File runtime/vm/intermediate_language.cc (right):

https://codereview.chromium.org/246303004/diff/10001/runtime/vm/intermediate_...
runtime/vm/intermediate_language.cc:2052: // OS::PrintErr("REMAPPING register
xx(%d)\n", loc.reg());
Remove commented-out code.

https://codereview.chromium.org/246303004/diff/10001/runtime/vm/intermediate_...
runtime/vm/intermediate_language.cc:2072: // TODO(turnidge): Can materialized
objects refer to other
I think right now this is the case - it may change in the future if we want to
do allocation sinking for nested objects: Currently, we perform only one
iteration of allocation sinking. If we did it iteratively, then one materialize
object could reference another.

Also, a materialized object can't have a reference to itself, since all stores
would make the allocation-site aliased and therefore not considered a sinking
candidate.

[turnidge, 2014-04-25 20:16:33]

https://codereview.chromium.org/246303004/diff/10001/runtime/vm/intermediate_...
File runtime/vm/intermediate_language.cc (right):

https://codereview.chromium.org/246303004/diff/10001/runtime/vm/intermediate_...
runtime/vm/intermediate_language.cc:2052: // OS::PrintErr("REMAPPING register
xx(%d)\n", loc.reg());
On 2014/04/25 05:55:33, Florian Schneider wrote:
> Remove commented-out code.

Done.

https://codereview.chromium.org/246303004/diff/10001/runtime/vm/intermediate_...
runtime/vm/intermediate_language.cc:2072: // TODO(turnidge): Can materialized
objects refer to other
On 2014/04/25 05:55:33, Florian Schneider wrote:
> I think right now this is the case - it may change in the future if we want to
> do allocation sinking for nested objects: Currently, we perform only one
> iteration of allocation sinking. If we did it iteratively, then one
materialize
> object could reference another.
> 
> Also, a materialized object can't have a reference to itself, since all stores
> would make the allocation-site aliased and therefore not considered a sinking
> candidate.

Updated comment.

[turnidge, 2014-04-25 20:24:50]

Committed patchset #4 manually as r35443 (presubmit successful).