Take advantage of batched results when matching global regexp.

Take advantage of batched results when matching global regexp.

BUG=
TEST=regexp-global.js

Committed: https://code.google.com/p/v8/source/detail?r=12258

[Yang, 2012-08-02 12:11:53]

Please take a look.

This CL includes:

- rewrite of some cases of String.replace and String.match in runtime.cc. We now
take advantage of batched results when running global regexps.
- only set the last match info of successful matches lazily at the end of a
matching loop for the very last successful match, instead of eagerly setting the
last match info after every successful match.
- added RegExpImpl::GlobalCache* methods in jsregexp.cc and jsregexp.h that
encapsulate running global regexp and fetching single results (for both irregexp
and atom regexp).
- change interpreted regexp engine to adjust to the changes.
- refactorings to get rid of unnecessary indirections
- removal of dead code.

Starting from jsregexp.h and jsregexp.cc and then move over to runtime.cc is
probably best. The rest are either tests or small changes due to refactoring.

[ulan, 2012-08-03 07:44:27]

Few nits apart from what we discussed offline.

http://codereview.chromium.org/10831126/diff/1/src/jsregexp.h
File src/jsregexp.h (right):

http://codereview.chromium.org/10831126/diff/1/src/jsregexp.h#newcode123
src/jsregexp.h:123: static int GlobalOffsetsVectorSize(Handle<JSRegExp> regexp,
Looks like this function is not used anymore.

http://codereview.chromium.org/10831126/diff/1/src/jsregexp.h#newcode148
src/jsregexp.h:148: // Set last match info.   If match is NULL, then setting
captures is omitted.
Double spaces in the comments for the functions below.

http://codereview.chromium.org/10831126/diff/1/src/jsregexp.h#newcode165
src/jsregexp.h:165: INLINE(static int32_t* GlobalCacheFetchNext(Handle<JSRegExp>
regexp,
Can we put this function in .cc file, it seems to be too large to be inlineable.

http://codereview.chromium.org/10831126/diff/1/src/jsregexp.h#newcode168
src/jsregexp.h:168: // The cache must not be clobbered.
Stale comment?

[Yang, 2012-08-03 11:37:42]

I addressed the comments and put GlobalCache* and the static vars that store the
state into a new class.

http://codereview.chromium.org/10831126/diff/1/src/jsregexp.h
File src/jsregexp.h (right):

http://codereview.chromium.org/10831126/diff/1/src/jsregexp.h#newcode123
src/jsregexp.h:123: static int GlobalOffsetsVectorSize(Handle<JSRegExp> regexp,
On 2012/08/03 07:44:27, ulan wrote:
> Looks like this function is not used anymore.

Done.

http://codereview.chromium.org/10831126/diff/1/src/jsregexp.h#newcode148
src/jsregexp.h:148: // Set last match info.   If match is NULL, then setting
captures is omitted.
On 2012/08/03 07:44:27, ulan wrote:
> Double spaces in the comments for the functions below.

Done.

http://codereview.chromium.org/10831126/diff/1/src/jsregexp.h#newcode165
src/jsregexp.h:165: INLINE(static int32_t* GlobalCacheFetchNext(Handle<JSRegExp>
regexp,
On 2012/08/03 07:44:27, ulan wrote:
> Can we put this function in .cc file, it seems to be too large to be
inlineable.

Done.

http://codereview.chromium.org/10831126/diff/1/src/jsregexp.h#newcode168
src/jsregexp.h:168: // The cache must not be clobbered.
On 2012/08/03 07:44:27, ulan wrote:
> Stale comment?

Done.

[ulan, 2012-08-03 11:58:05]

http://codereview.chromium.org/10831126/diff/3002/src/jsregexp.cc
File src/jsregexp.cc (right):

http://codereview.chromium.org/10831126/diff/3002/src/jsregexp.cc#newcode661
src/jsregexp.cc:661: output_registers = NewArray<int32_t>(required_registers);
Where does this array get released?

http://codereview.chromium.org/10831126/diff/3002/src/jsregexp.cc#newcode753
src/jsregexp.cc:753: last_match[0] = -1;
This assumes that registers_per_match_ >= 2. If this condition always holds, can
we add a comment explaining why?   

Why don't we initialize the remaining registers if registers_per_match_ > 2?

[Yang, 2012-08-03 12:58:15]

On 2012/08/03 11:58:05, ulan wrote:
> http://codereview.chromium.org/10831126/diff/3002/src/jsregexp.cc
> File src/jsregexp.cc (right):
> 
> http://codereview.chromium.org/10831126/diff/3002/src/jsregexp.cc#newcode661
> src/jsregexp.cc:661: output_registers = NewArray<int32_t>(required_registers);
> Where does this array get released?
> 
> http://codereview.chromium.org/10831126/diff/3002/src/jsregexp.cc#newcode753
> src/jsregexp.cc:753: last_match[0] = -1;
> This assumes that registers_per_match_ >= 2. If this condition always holds,
can
> we add a comment explaining why?   
> 
> Why don't we initialize the remaining registers if registers_per_match_ > 2?

Addressed comments. Please take another look.

[Yang, 2012-08-03 12:58:22]

http://codereview.chromium.org/10831126/diff/3002/src/jsregexp.cc
File src/jsregexp.cc (right):

http://codereview.chromium.org/10831126/diff/3002/src/jsregexp.cc#newcode753
src/jsregexp.cc:753: last_match[0] = -1;
On 2012/08/03 11:58:05, ulan wrote:
> This assumes that registers_per_match_ >= 2. If this condition always holds,
can
> we add a comment explaining why?   
> 
> Why don't we initialize the remaining registers if registers_per_match_ > 2?

Registers generally don't need initializing. I initialize those two registers so
that the first FetchNext picks up those two values as last_end_index and
last_start_index to know at which index to start.

[ulan, 2012-08-03 14:02:54]

LGTM