Clean up some naming.

Clean up some naming to be consistent between runtime and JS code.

[Dean McNamee, 2008-09-20 14:06:39]

This "fixes" our 10% regression on a string benchmark.  I was only able to
reproduce the regression on a P4 system.  I'd like to know better what was going
on, but there was too many things that changed.  I diffed the generated code,
and it looks like it comes down to either 1) stack size increase, but I don't
think this was it, 2) register allocation, there were a few spots where the
compiler used the stack instead of a register, 3) code size.  I would say it's
mostly 3, which is strange.  It didn't look like any of the branching or
anything else changed.  I can dig into it further if needed.

I think moving this code out makes sense anyway, and we get better numbers that
before on this test, which is a bit unexpected.  In general, I'd like to
understand the P4 performance issues better, if anyone has insight, I'd love to
know.

[Erik Corry, 2008-09-20 15:53:26]

http://codereview.chromium.org/3181/diff/1/2
File src/runtime.cc (left):

http://codereview.chromium.org/3181/diff/1/2#oldcode921
Line 921: if (!Array::IndexFromObject(index, &start_index)) return
Smi::FromInt(-1);
As you pointed out in mail we have to have this check in the C code.  I wonder
whether you could put it back in without losing performance.  It could be that
the performance gain you are seeing just comes from not doing the rather slow
runtime call in the pattern_length==0 case?

Apart from this LGTM

[Mads Ager (chromium), 2008-09-22 07:43:05]

LGTM