Make stackmaps store their actual length.

Make stackmaps store their actual length.

This allows stackmaps with varying lengths in the same function, necessary
for the way we plan to support bitmaps for saved live registers.

R=vegorov@google.com
BUG=

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

[Kevin Millikin (Google), 2012-08-17 09:07:43]

https://chromiumcodereview.appspot.com/10837303/diff/1/runtime/vm/bitmap.h
File runtime/vm/bitmap.h (left):

https://chromiumcodereview.appspot.com/10837303/diff/1/runtime/vm/bitmap.h#ol...
runtime/vm/bitmap.h:45: void SetBits(const Stackmap& stackmap);
This function is unused and doesn't seem useful at the moment.

https://chromiumcodereview.appspot.com/10837303/diff/1/runtime/vm/code_descri...
File runtime/vm/code_descriptors_test.cc (left):

https://chromiumcodereview.appspot.com/10837303/diff/1/runtime/vm/code_descri...
runtime/vm/code_descriptors_test.cc:241: stack_bitmap->Set(5, true);  // First
argument to func(i, k).
This test is really brittle and will soon be replaced by one that uses a real,
not hand-constructed, stackmap.

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

https://chromiumcodereview.appspot.com/10837303/diff/1/runtime/vm/object.h#ol...
runtime/vm/object.h:2539: intptr_t spill_slot_count() const {
This is no longer used, and it's easy to add back if we need it.

[Vyacheslav Egorov (Google), 2012-08-20 12:22:12]

lgtm

[srdjan, 2012-08-21 16:06:04]

DBC, questions.

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

https://chromiumcodereview.appspot.com/10837303/diff/1/runtime/vm/code_descri...
runtime/vm/code_descriptors.h:86: const intptr_t entry_length_;
Why did you remove the _in_bits?  I assume it is now in bytes

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

https://chromiumcodereview.appspot.com/10837303/diff/1/runtime/vm/object.cc#n...
runtime/vm/object.cc:6940: void Stackmap::SetCode(const dart::Code& code) const
{
Why dart:: ?

https://chromiumcodereview.appspot.com/10837303/diff/1/runtime/vm/object.cc#n...
runtime/vm/object.cc:6980: (kSmiMax -
static_cast<intptr_t>(sizeof(RawStackmap)))) {
Add parenthesis

[Kevin Millikin (Google), 2012-08-22 07:34:18]

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

https://chromiumcodereview.appspot.com/10837303/diff/1/runtime/vm/code_descri...
runtime/vm/code_descriptors.h:86: const intptr_t entry_length_;
On 2012/08/21 16:06:04, srdjan wrote:
> Why did you remove the _in_bits?  I assume it is now in bytes

No, it's the number of entries in each stackmap.  Internally, there is one bit
per entry but that is an implementation detail.  I got rid of the _in_bits part
because I don't think it matters.

I'm happy to see the name change if there are better alternatives (note that
this field is already eliminated in a change that I have out for review).

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

https://chromiumcodereview.appspot.com/10837303/diff/1/runtime/vm/object.cc#n...
runtime/vm/object.cc:6940: void Stackmap::SetCode(const dart::Code& code) const
{
On 2012/08/21 16:06:04, srdjan wrote:
> Why dart:: ?

Because C++.

Class Code is shadowed by the accessor member function Stackmap::Code() so it
needs to be qualified.

The previous solution was to use a different naming scheme from the rest of the
Stackmap class for that one function.  I thought qualifying class Code in two
signatures was less intrusive.

https://chromiumcodereview.appspot.com/10837303/diff/1/runtime/vm/object.cc#n...
runtime/vm/object.cc:6980: (kSmiMax -
static_cast<intptr_t>(sizeof(RawStackmap)))) {
On 2012/08/21 16:06:04, srdjan wrote:
> Add parenthesis

OK.  Incorporated in an outstanding change list.