Introduce read buffer for external strings when using charAt (ia32).

Introduce read buffer for external strings when using charAt (ia32).

TEST=test/mjsunit/string-externalize.js

[Yang, 2011-11-15 18:09:20]

Please take a look.

This CL adds a read buffer to long external strings. Short ones (less than
kMinBufferedLength) stay the way they are. Long ones are extended by an attached
buffer that caches a substring of the external string. The rationale for this is
that reading from the buffer does not require calling to the runtime. In
particular, this benefits http://code.google.com/p/v8/issues/detail?id=1750

When we use String.charAt(index) on an external string, the generated code check
whether the indexed character is in the buffered substring. If not, the runtime
call updates the buffer to contain a substring around the indexed char. In the
case of sequential access, buffering pays off the next time we access the
external string from generated code.

When making a cons or slice that depend on an external string and is long enough
to be buffered, the string cannot be simply morphed into an external string due
to size constraints. In this case it is morphed into a sliced string, which
points to a newly allocated external string.

This CL also unifies the non-crankshaft and the crankshaft version of
charCodeAt, which only differ in smi-ness of the index argument. The additional
smi-tagging has close to no impact on performance here.

The performance of reading sequentially forward through an external string using
charAt gains 75%. Reading sequentially backward gains 68%. Reading randomly
drops by 37% due to unnecessary buffer updates.

x64 and arm ports are going to follow shortly.

[Vitaly Repeshko, 2011-11-15 18:25:21]

Here's an interesting fact about ExternalStringResource::data(). Its current
contract actually requires the embedder to keep the returned char array pointer
alive until the resource is destructed. It means that the pointer can be cached
in the C++ resource object at a known offset and accessed from our generated
code. Of course, it makes the resource object one word larger, but similar to
this patch it can save a lot of runtime calls. Have you considered this
approach?


-- Vitaly

[Lasse Reichstein, 2011-11-15 19:12:14]

My immediate thought would be the same: If we have a word to spare in the String
structure, we might as well let it point directly to the real character data
instead of pointing to an intermediate buffer.
It might require tweaking of GC, since it would be a native pointer, but so is
the resource pointer, so it should be doable.

We were considering adding such a pointer recently, but the overhead of adding
an extra pointer to all external strings seemed steep. It's a good idea to only
do it to some strings.