Make DeltaBlue performance more stable by ignoring type feedback that

Make DeltaBlue performance more stable by ignoring type feedback that
tells us that a map can transition to another map when we are generating
code for load operations.  This may cause us to deopt if the same routine
is seeing different maps caused by branching in constructors.  If so, I
have a different change that is around 100 times more complicated that
lets us generated Crankshaft code for negative lookups.
Committed: https://code.google.com/p/v8/source/detail?r=11524

[Michael Starzinger, 2012-05-02 13:39:28]

https://chromiumcodereview.appspot.com/10306010/diff/1/src/hydrogen-instructi...
File src/hydrogen-instructions.cc (right):

https://chromiumcodereview.appspot.com/10306010/diff/1/src/hydrogen-instructi...
src/hydrogen-instructions.cc:1628: case MAP_TRANSITION:
I think that check is not general enough. We have a transition whenever
"lookup.IsFound() && !lookup.IsProperty()". Esepcially with Sven's new accessor
pairs in mind.

[Sven Panne, 2012-05-02 13:54:59]

https://chromiumcodereview.appspot.com/10306010/diff/1/src/hydrogen-instructi...
File src/hydrogen-instructions.cc (right):

https://chromiumcodereview.appspot.com/10306010/diff/1/src/hydrogen-instructi...
src/hydrogen-instructions.cc:1628: case MAP_TRANSITION:
On 2012/05/02 13:39:29, Michael Starzinger wrote:
> I think that check is not general enough. We have a transition whenever
> "lookup.IsFound() && !lookup.IsProperty()". Esepcially with Sven's new
accessor
> pairs in mind.

Michael's comment is correct, but things are even more tricky, because the
PropertyType alone is not enough to decide if we have a transition or not: In
the CALLBACKS case you have to look into the AccessorPair to decide if we have a
transition or not. And without a holder (see "NULL" above), this won't work...
(see LookupResult::IsProperty).

https://chromiumcodereview.appspot.com/10306010/diff/1/src/hydrogen-instructi...
src/hydrogen-instructions.cc:1633: default:
We should never use a default case when doing a switch over the property type,
because this makes finding all the places where things have to be changed when
fiddling around with those types (e.g. adding a new type, changing the behaviour
for a given type, etc.) virtually impossible. I've been down that road several
times in the last few months... :-P

[Erik Corry, 2012-05-03 10:39:14]

https://chromiumcodereview.appspot.com/10306010/diff/1/src/hydrogen-instructi...
File src/hydrogen-instructions.cc (right):

https://chromiumcodereview.appspot.com/10306010/diff/1/src/hydrogen-instructi...
src/hydrogen-instructions.cc:1628: case MAP_TRANSITION:
On 2012/05/02 13:55:00, Sven Panne wrote:
> On 2012/05/02 13:39:29, Michael Starzinger wrote:
> > I think that check is not general enough. We have a transition whenever
> > "lookup.IsFound() && !lookup.IsProperty()". Esepcially with Sven's new
> accessor
> > pairs in mind.
> 
> Michael's comment is correct, but things are even more tricky, because the
> PropertyType alone is not enough to decide if we have a transition or not: In
> the CALLBACKS case you have to look into the AccessorPair to decide if we have
a
> transition or not. And without a holder (see "NULL" above), this won't work...
> (see LookupResult::IsProperty).

All I want to do is to ignore this particular map when generating optimized
code.  If we actually encounter it we will deopt.  I don't actually care much
whether there is a real map transition from this map to another one.

https://chromiumcodereview.appspot.com/10306010/diff/1/src/hydrogen-instructi...
src/hydrogen-instructions.cc:1633: default:
On 2012/05/02 13:55:00, Sven Panne wrote:
> We should never use a default case when doing a switch over the property type,
> because this makes finding all the places where things have to be changed when
> fiddling around with those types (e.g. adding a new type, changing the
behaviour
> for a given type, etc.) virtually impossible. I've been down that road several
> times in the last few months... :-P

I didn't add this default clause.  All it is saying is that if there is another
kind of property then Crankshaft does not understand it and will not generate
optimized code for it.  If a new kind of property is added this is certainly the
correct behaviour, so I see no reason to change this, but you are welcome to try
in a different CL.

[Michael Starzinger, 2012-05-03 14:12:22]

OK, I looked through the CL again. So basically the switch is just a
conservative estimate to detect all lookup results that are real properties for
sure. And what you added is that MAP_TRANSITIONs (which are transitions for
sure) will cause a deopt instead of forcing a generic LoadIC. I get it now.

LGTM. Sorry for the confusion.

https://chromiumcodereview.appspot.com/10306010/diff/1/src/hydrogen-instructi...
File src/hydrogen-instructions.cc (right):

https://chromiumcodereview.appspot.com/10306010/diff/1/src/hydrogen-instructi...
src/hydrogen-instructions.cc:1630: // operation.
In this case, this comment should contain something like "... and possibly
deoptimize in these cases".