Deoptimization can occur at Dart calls (includes native calls to C) but not at runtime calls. This …

Deoptimization can occur at Dart calls (includes native calls to C) but not at runtime calls. This assumption (verified with Todd and Gilad) simplifies the implementation of lazy deoptimization considerably.

Add flag --deoptimize-alot, which will lazily deoptimize all live optimized frames. Currently only the presence of deoptimization information is checked.

Add kDeoptAfter deoptimization point, which is the continuation for lazy deoptimization, after a call. Rename kDeopt to kDeoptBefore.

Removed a tests case that called into a native without properly setting up a Dart frame (Ok-d by Siva).

Native functions are not optimizable.

TODO: Split deoptimization information from DeoptimizationStubs. Check for redundant PcDescriptor information (what can be merged, especially at calls).
Committed: https://code.google.com/p/dart/source/detail?r=11642

[siva, 2012-08-30 01:37:30]

LGTM once question regarding access to
GetDeoptBeforePcAtDeoptId on unoptimized code is addressed.

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_des...
File runtime/vm/code_descriptors.cc (right):

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_des...
runtime/vm/code_descriptors.cc:36: data.token_index = deopt_reason;
overloading token_index field as deopt_reason can be a bit confusing when
reading code.

I am wondering if it would make the code more readable if we called the field
data and added accessor functions
SetTokenIndex(intptr_t value);
intptr_t TokenIndex();
SetDeoptReason(intptr_t value);
intptr_t DeoptReason();

and used these accessor functions.

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_gen...
File runtime/vm/code_generator.cc (right):

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_gen...
runtime/vm/code_generator.cc:30: "Deoptimizes all live frames at runtime and
native entries.");
Deoptimizes all live frames when we are about to return to dart code from
runtime and native entries?

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_gen...
runtime/vm/code_generator.cc:1404: StackFrame* frame = iterator.NextFrame();
Code& optimized_code = Code::Handle();
Function& function = Function::Handle();
Code& unoptimized_code = Code::Handle();

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_gen...
runtime/vm/code_generator.cc:1406: const Code& optimized_code =
Code::Handle(frame->LookupDartCode());
optimized_code = frame->LookupDartCode();

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_gen...
runtime/vm/code_generator.cc:1412: const Function& function =
Function::Handle(optimized_code.function());
function = optimized_code.function();
unoptimized_code = function.unoptimzied_code();

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_gen...
runtime/vm/code_generator.cc:1417: ASSERT(continue_at_pc != 0);
Maybe also assert that
continue_at_pc > unoptimized_code.EntryPoint() &&
continue_at_pc < (unoptimized_code.EntryPoint() + unoptimized_code.Size())

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_gen...
runtime/vm/code_generator.cc:1591: uword continue_at_pc =
unoptimized_code.GetDeoptBeforePcAtDeoptId(deopt_id);
I am a little confused I thought unoptimized_code should only have DeoptAfter
entries?

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/deopt_in...
File runtime/vm/deopt_instructions.cc (right):

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/deopt_in...
runtime/vm/deopt_instructions.cc:104:
code.GetDeoptBeforePcAtDeoptId(deopt_id_as_smi.Value());
Ditto question about unoptimized code having a DeoptBefore entry?

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/native_e...
File runtime/vm/native_entry.h (right):

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/native_e...
runtime/vm/native_entry.h:37: extern void DeoptimizeAll();                      
                          \
why not include "code_generator.h" in this file instead of this extern void
DeoptimizeAll declaration.

[srdjan, 2012-08-30 17:16:16]

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_des...
File runtime/vm/code_descriptors.cc (right):

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_des...
runtime/vm/code_descriptors.cc:36: data.token_index = deopt_reason;
On 2012/08/30 01:37:30, asiva wrote:
> overloading token_index field as deopt_reason can be a bit confusing when
> reading code.
> 
> I am wondering if it would make the code more readable if we called the field
> data and added accessor functions
> SetTokenIndex(intptr_t value);
> intptr_t TokenIndex();
> SetDeoptReason(intptr_t value);
> intptr_t DeoptReason();
> 
> and used these accessor functions.


Done.

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_gen...
File runtime/vm/code_generator.cc (right):

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_gen...
runtime/vm/code_generator.cc:30: "Deoptimizes all live frames at runtime and
native entries.");
On 2012/08/30 01:37:30, asiva wrote:
> Deoptimizes all live frames when we are about to return to dart code from
> runtime and native entries?

Done, removed reference to runtime.

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_gen...
runtime/vm/code_generator.cc:1404: StackFrame* frame = iterator.NextFrame();
On 2012/08/30 01:37:30, asiva wrote:
> Code& optimized_code = Code::Handle();
> Function& function = Function::Handle();
> Code& unoptimized_code = Code::Handle();

Done.

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_gen...
runtime/vm/code_generator.cc:1406: const Code& optimized_code =
Code::Handle(frame->LookupDartCode());
On 2012/08/30 01:37:30, asiva wrote:
> optimized_code = frame->LookupDartCode();

Done.

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_gen...
runtime/vm/code_generator.cc:1412: const Function& function =
Function::Handle(optimized_code.function());
On 2012/08/30 01:37:30, asiva wrote:
> function = optimized_code.function();
> unoptimized_code = function.unoptimzied_code();

Done.

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_gen...
runtime/vm/code_generator.cc:1417: ASSERT(continue_at_pc != 0);
On 2012/08/30 01:37:30, asiva wrote:
> Maybe also assert that
> continue_at_pc > unoptimized_code.EntryPoint() &&
> continue_at_pc < (unoptimized_code.EntryPoint() + unoptimized_code.Size())

This check belongs in GetDeoptAfterPcAtDeoptId. Adding it there.

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/code_gen...
runtime/vm/code_generator.cc:1591: uword continue_at_pc =
unoptimized_code.GetDeoptBeforePcAtDeoptId(deopt_id);
On 2012/08/30 01:37:30, asiva wrote:
> I am a little confused I thought unoptimized_code should only have DeoptAfter
> entries?

DeoptBefore an DeoptAfter are continuation points in unoptimized code. Added
more asserts that we can add them only to unoptimized code.
DeoptIndex can be added only to optimized code.

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/deopt_in...
File runtime/vm/deopt_instructions.cc (right):

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/deopt_in...
runtime/vm/deopt_instructions.cc:104:
code.GetDeoptBeforePcAtDeoptId(deopt_id_as_smi.Value());
On 2012/08/30 01:37:30, asiva wrote:
> Ditto question about unoptimized code having a DeoptBefore entry?

Ditto answer

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/native_e...
File runtime/vm/native_entry.h (right):

https://chromiumcodereview.appspot.com/10885039/diff/7026/runtime/vm/native_e...
runtime/vm/native_entry.h:37: extern void DeoptimizeAll();                      
                          \
On 2012/08/30 01:37:30, asiva wrote:
> why not include "code_generator.h" in this file instead of this extern void
> DeoptimizeAll declaration.

Done.