Enable slices of external strings (in the tentative implementation).

Enable slices of external strings (in the tentative implementation).
TEST=cctest test-strings/SliceFromExternal, mjsunit/string-slices.js

Committed: http://code.google.com/p/v8/source/detail?r=9295

[Yang, 2011-09-02 15:06:02]

The problem with slice having a different encoding that the backing string (due
to externalizing) is not really a problem anymore since that - as far as I could
see - only affected  ToAsciiVector and ToUC16Vector that have been replaced
recently by GetFlatContent.

[Yang, 2011-09-12 13:55:52]

On 2011/09/02 15:06:02, Yang wrote:
> The problem with slice having a different encoding that the backing string
(due
> to externalizing) is not really a problem anymore since that - as far as I
could
> see - only affected  ToAsciiVector and ToUC16Vector that have been replaced
> recently by GetFlatContent.

I still need an opinion on this issue before I can land this and be done with
string slices.

[Vitaly Repeshko, 2011-09-13 18:20:25]

LGTM if we have good test coverage.

http://codereview.chromium.org/7832002/diff/1/src/heap.cc
File src/heap.cc (right):

http://codereview.chromium.org/7832002/diff/1/src/heap.cc#newcode2669
src/heap.cc:2669: // The string encoding of the string might be ascii, while the
underlying
Let's just replace this with
"WriteToFlat takes care of the case when an indirect string has a different
encoding from its underlying string. These encodings may differ because of
externalization."

http://codereview.chromium.org/7832002/diff/1/src/heap.cc#newcode2699
src/heap.cc:2699: // The string encoding tag in the newly created slice does not
really matter.
"When slicing an indirect string we use its encoding for a newly created slice
and don't check the encoding of the underlying string. This is safe even if the
encodings are different because of externalization. If an indirect ASCII string
is pointing to a two-byte string, the two-byte char codes of the underlying
string must still fit into ASCII (because externalization must not change char
codes)."

http://codereview.chromium.org/7832002/diff/1/test/cctest/test-strings.cc
File test/cctest/test-strings.cc (right):

http://codereview.chromium.org/7832002/diff/1/test/cctest/test-strings.cc#new...
test/cctest/test-strings.cc:517: TEST(SliceFromExternal) {
Do we have a test for the case of the underlying string changing its encoding
from ASCII to two-byte?

http://codereview.chromium.org/7832002/diff/1/test/cctest/test-strings.cc#new...
test/cctest/test-strings.cc:526: // After slicing, the original string becomes a
flat cons.
Update the comment.

[Yang, 2011-09-15 11:01:22]

Updated those comments. Test coverage is given imo. I'll land.

http://codereview.chromium.org/7832002/diff/1/test/cctest/test-strings.cc
File test/cctest/test-strings.cc (right):

http://codereview.chromium.org/7832002/diff/1/test/cctest/test-strings.cc#new...
test/cctest/test-strings.cc:517: TEST(SliceFromExternal) {
On 2011/09/13 18:20:25, Vitaly Repeshko wrote:
> Do we have a test for the case of the underlying string changing its encoding
> from ASCII to two-byte?

Both the cctest test-api/MorphCompositeStringTest and the last part of
mjsunit/string-slices.js test this.