Adding deopt info to code object.

Adding deopt info to code object.
Committed: https://code.google.com/p/dart/source/detail?r=10189

[siva, 2012-08-02 16:57:37]

One question regarding mapping the index into the deopt info array as the
to-index.

LGTM otherwise.

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/code_descri...
File runtime/vm/code_descriptors.h (right):

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/code_descri...
runtime/vm/code_descriptors.h:21: intptr_t try_index;        // Try block index
of PC.
update the comment to indicate it is try block index or deopt array index.

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/object.cc#n...
runtime/vm/object.cc:6922: 
For better readability it might make sense to also have a
intptr_t DeoptInfo::ToIndex(intptr_t index) const {
  return index;
}

method  and use this consistently instead of index directly.

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/object.cc#n...
runtime/vm/object.cc:7081:
result.set_object_table(Array::Handle(Array::Empty()));
Is there an advantage to initializing these to empty arrays as opposed to
leaving them as null objects?

I am presuming you would have to do a set_deopt_info_array and set_object_table
after generating code for the method at that point you could set them to empty
arrays if there is no deopt info at all for the method.

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/object.h
File runtime/vm/object.h (right):

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/object.h#ne...
runtime/vm/object.h:2408: // Describes the layout of deopt info data.
You should also mention here that the index of the deopt-info entry is
implicitly the stack slot in the unoptimized frame into which the value is
written into.

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/object.h#ne...
runtime/vm/object.h:2434: // 'index' corresponds to target, to-index.
We have one deopt_info array per code object and we will have multiple deopt-ix
pc descriptor entries pointing into this deopt info array. For the first pc
descriptor entry I can see how index and to-index map nicely but for the
subsequent ones you would have to do subtract index from the start index right?
I am little confused by this maybe you can explain offline.

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/raw_object.cc
File runtime/vm/raw_object.cc (right):

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/raw_object....
runtime/vm/raw_object.cc:236: intptr_t num_handlers =
Smi::Value(raw_handlers->ptr()->length_);
num_handlers => num_entries ?
as these are not exception handler entries but just deopt entries.

similarly instead of raw_handlers raw_deoptinfo

[srdjan, 2012-08-02 17:51:44]

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/code_descri...
File runtime/vm/code_descriptors.h (right):

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/code_descri...
runtime/vm/code_descriptors.h:21: intptr_t try_index;        // Try block index
of PC.
On 2012/08/02 16:57:37, asiva wrote:
> update the comment to indicate it is try block index or deopt array index.

Done.

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/object.cc#n...
runtime/vm/object.cc:6922: 
On 2012/08/02 16:57:37, asiva wrote:
> For better readability it might make sense to also have a
> intptr_t DeoptInfo::ToIndex(intptr_t index) const {
>   return index;
> }
> 
> method  and use this consistently instead of index directly.

Done

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/object.cc#n...
runtime/vm/object.cc:7081:
result.set_object_table(Array::Handle(Array::Empty()));
On 2012/08/02 16:57:37, asiva wrote:
> Is there an advantage to initializing these to empty arrays as opposed to
> leaving them as null objects?
> 
> I am presuming you would have to do a set_deopt_info_array and
set_object_table
> after generating code for the method at that point you could set them to empty
> arrays if there is no deopt info at all for the method.

Removed code, setting them to NULL.

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/object.h
File runtime/vm/object.h (right):

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/object.h#ne...
runtime/vm/object.h:2434: // 'index' corresponds to target, to-index.
On 2012/08/02 16:57:37, asiva wrote:
> We have one deopt_info array per code object and we will have multiple
deopt-ix
> pc descriptor entries pointing into this deopt info array. For the first pc
> descriptor entry I can see how index and to-index map nicely but for the
> subsequent ones you would have to do subtract index from the start index
right?
> I am little confused by this maybe you can explain offline.

Discussed offline. There is another level of indirection: deopt-ix points to an
array of DeoptInfo objects.

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/raw_object.cc
File runtime/vm/raw_object.cc (right):

https://chromiumcodereview.appspot.com/10830131/diff/1/runtime/vm/raw_object....
runtime/vm/raw_object.cc:236: intptr_t num_handlers =
Smi::Value(raw_handlers->ptr()->length_);
On 2012/08/02 16:57:37, asiva wrote:
> num_handlers => num_entries ?
> as these are not exception handler entries but just deopt entries.
> 
> similarly instead of raw_handlers raw_deoptinfo

Done.