Shrink the size of deoptimization_counter_ and kind_tag_ fields. This

Shrink the size of deoptimization_counter_ and kind_tag_ fields. This
compensates for the new num_optional_named_parameters_ field.
Committed: https://code.google.com/p/dart/source/detail?r=12226

[regis, 2012-09-11 20:53:57]

LGTM

[srdjan, 2012-09-12 06:37:05]

LGTM

https://chromiumcodereview.appspot.com/10905220/diff/1/vm/raw_object.h
File vm/raw_object.h (right):

https://chromiumcodereview.appspot.com/10905220/diff/1/vm/raw_object.h#newcod...
vm/raw_object.h:618: intptr_t usage_counter_;  // Incremented while function is
running.
Why not move the numbers of parameters to uint16 as well?
The usage_counter could be int32_t, which would help on x64 architectures.

[regis, 2012-09-12 15:42:27]

https://chromiumcodereview.appspot.com/10905220/diff/1/vm/raw_object.h
File vm/raw_object.h (right):

https://chromiumcodereview.appspot.com/10905220/diff/1/vm/raw_object.h#newcod...
vm/raw_object.h:618: intptr_t usage_counter_;  // Incremented while function is
running.
On 2012/09/12 06:37:05, srdjan wrote:
> Why not move the numbers of parameters to uint16 as well?
> The usage_counter could be int32_t, which would help on x64 architectures.

I would be reluctant to restrict the maximum number of parameters to 64K
(uint32_t). I can well imagine tests targeting this limitation.
However, since positional and named optional parameters are mutually exclusive,
one intptr_t field and one bool field would suffice. The problem is that a bool
field does not save us anything with the current layout of existing fields.

[regis, 2012-09-12 17:09:59]

On 2012/09/12 15:42:27, regis wrote:
> https://chromiumcodereview.appspot.com/10905220/diff/1/vm/raw_object.h
> File vm/raw_object.h (right):
> 
>
https://chromiumcodereview.appspot.com/10905220/diff/1/vm/raw_object.h#newcod...
> vm/raw_object.h:618: intptr_t usage_counter_;  // Incremented while function
is
> running.
> On 2012/09/12 06:37:05, srdjan wrote:
> > Why not move the numbers of parameters to uint16 as well?
> > The usage_counter could be int32_t, which would help on x64 architectures.
> 
> I would be reluctant to restrict the maximum number of parameters to 64K
> (uint32_t). I can well imagine tests targeting this limitation.
> However, since positional and named optional parameters are mutually
exclusive,
> one intptr_t field and one bool field would suffice. The problem is that a
bool
> field does not save us anything with the current layout of existing fields.

Sorry, I read your message as int16_t.
Yes, I think it would help with int32_t. Actually, I could store the bool I
mentioned as a negative number of optional parameters.

So instead of
intptr_t num_fixed_parameters_;
intptr_t num_optional_positional_parameters_;
intptr_t num_optional_named_parameters_;

We would have
int32_t num_fixed_parameters_;
int32_t num_optional_parameters_;  // > 0: positional; < 0: named.

I'll give it a try.