Convert sliced strings into sequential strings when promoting into old space.

Convert sliced strings into sequential strings when promoting into old space.
TEST=cctest test-strings/SliceConversion

[Yang, 2011-08-29 14:30:13]

Please take a look.

[Erik Corry, 2011-08-29 20:17:24]

This change worries me.  This can cause a space explosion during GC for
pathological cases.  It also adds a new case where strings can change shape,
which has historically been a source of nasty bugs (the cons string
short-circuiting).  Do we have benchmark figures that support the change?

[Vitaly Repeshko, 2011-08-30 00:51:01]

This need more work.

Even if we stop simplifying sliced strings when running out of memory during GC,
it can hurt other object types that can't tolerate allocation failures.

Whatever scheme we come up with should be memory efficient. In other words,
simplifying slices should not increase total memory usage.

And as Erik points out this change can cause subtle bugs when a string shape is
changed after being inspected. Have you verified our runtime and generated code
to be immune to this?


Thanks,
Vitaly

[Yang, 2011-09-07 14:17:35]

On 2011/08/30 00:51:01, Vitaly Repeshko wrote:
> This need more work.
> 
> Even if we stop simplifying sliced strings when running out of memory during
GC,
> it can hurt other object types that can't tolerate allocation failures.
> 
> Whatever scheme we come up with should be memory efficient. In other words,
> simplifying slices should not increase total memory usage.
> 
> And as Erik points out this change can cause subtle bugs when a string shape
is
> changed after being inspected. Have you verified our runtime and generated
code
> to be immune to this?
> 
> 
> Thanks,
> Vitaly

After reviewing the implementation in Firefox and doing some more testing, I
think leaving this as is would be the best option. Parent strings will be kept
in the memory as long as slices that point to them stay alive, but the chance of
doing that to a very long string is low and would not cause any problem.

[Vitaly Repeshko, 2011-09-08 17:22:24]

On 2011/09/07 14:17:35, Yang wrote:
> On 2011/08/30 00:51:01, Vitaly Repeshko wrote:
> > This need more work.
> > 
> > Even if we stop simplifying sliced strings when running out of memory during
> GC,
> > it can hurt other object types that can't tolerate allocation failures.
> > 
> > Whatever scheme we come up with should be memory efficient. In other words,
> > simplifying slices should not increase total memory usage.
> > 
> > And as Erik points out this change can cause subtle bugs when a string shape
> is
> > changed after being inspected. Have you verified our runtime and generated
> code
> > to be immune to this?
> > 
> > 
> > Thanks,
> > Vitaly
> 
> After reviewing the implementation in Firefox and doing some more testing, I
> think leaving this as is would be the best option. Parent strings will be kept
> in the memory as long as slices that point to them stay alive, but the chance
of
> doing that to a very long string is low and would not cause any problem.

Keeping things as they are seems fine. Yet I'm not sure the chances of retaining
huge strings this way are too low. For example, a web app could receive periodic
huge responses and keep small substrings from them. Let's at least file a bug to
track this issue.