Disable stack context when its frame is for optimized code.

Disable stack context when its frame is for optimized code.
Committed: https://code.google.com/p/dart/source/detail?r=19894

[Tom Ball, 2013-03-11 22:46:05]

I hope this is the fix you recommended this morning.

[Ivan Posva, 2013-03-12 16:31:25]

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

https://codereview.chromium.org/12408015/diff/1/runtime/vm/debugger.cc#newcod...
runtime/vm/debugger.cc:895: }
What I am concerned about is this scenario:

Traversing from top-of-stack you have a set of unoptimized frames, followed by a
set of optimized frames, followed by a set of unoptimized frames.

The set of optimized frames is handled perfectly fine with your change in
ContextLevel(), but the unoptimized frames below the optimized frames also
cannot rely on the contexts to be set up properly when we get to them. A
temporary solution would be to set ctx to the empty handle once we see an
optimized frame and keep that for all following frames.

P.S. There could be a way to recover the context chain once we have a set of
unoptimized frames, but I am not sure it warrants the complications.

[Tom Ball, 2013-03-12 20:29:27]

I added a flag CollectStackTrace as you suggested.

[Ivan Posva, 2013-03-12 20:36:25]

LGTM -ip

https://codereview.chromium.org/12408015/diff/5001/runtime/vm/debugger.cc
File runtime/vm/debugger.cc (right):

https://codereview.chromium.org/12408015/diff/5001/runtime/vm/debugger.cc#new...
runtime/vm/debugger.cc:308: if (code_.is_optimized()) {
I think we can change this test into an ASSERT(!code_.is_optimized()) as the
ActivationFrame is already created with a null context if the code is optimized.
Correct?

[Tom Ball, 2013-03-12 20:41:45]

https://codereview.chromium.org/12408015/diff/5001/runtime/vm/debugger.cc
File runtime/vm/debugger.cc (right):

https://codereview.chromium.org/12408015/diff/5001/runtime/vm/debugger.cc#new...
runtime/vm/debugger.cc:308: if (code_.is_optimized()) {
On 2013/03/12 20:36:25, Ivan Posva wrote:
> I think we can change this test into an ASSERT(!code_.is_optimized()) as the
> ActivationFrame is already created with a null context if the code is
optimized.
> Correct?

You're right, that test is no longer needed with the change to
CollectStackTrace.  Removed.

[Tom Ball, 2013-03-12 20:42:41]

Committed patchset #3 manually as r19894 (presubmit successful).