The previous implementation creates a substring as a full sequential string in new space and copies that full seq string into old space when it is promoted during scavenging. The proposed new version creates a substring as a slice (pointer to original, length and offset) and inflates it into a full seq string into old space when it is promoted during scavenging. In comparison, the new version does not require more memory than the old version. It merely postpones the creation of a full seq string for a substring, with the advantage that short-lived substrings are never promoted and inflated.
For this reason i think that, in any scenario that would cause an OOM in the new version would also have caused OOM in the old version, except the new version would notice the OOM some time later because it has yet to inflate the slices. (Conversely, a scenario that creates a lot short-lived substring with very large length would cause OOM in the old version, but would not hit the wall with the new version.) A way to avoid the space explosion (as mentioned by Erik) when promoting slices into old space is to reserve the same amount of space for string slices as we would have for their inflated seq string counter parts. This means that creating slices in new space wastes a lot of space, the new space fills up more quickly, resulting in more often scavenging/promoting, effectively shortening the time until a slice is inflated into a seq string, increasing the chance that a short-lived substring is unnecessarily inflated. Another option would to abandon this CL and promote slices into the old space. This then creates the problem that strings referenced to by slices will not be garbage collected even if they are not referenced elsewhere. This solution would actually be better performance-wise in the dromaeo strings benchmark, but only very slightly. I've seen the implementation for cons short-circuiting, from which I borrowed some code. Could you give me any pointers on where problems could arise when the string shape is changed during GC? Off the top of my head I can't think of any place in the code where GC may be invoked in between making a decision based on the string being a slice and extracting the slice's content. -Yang On Tue, Aug 30, 2011 at 2:51 AM, <[email protected]> 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 > > > http://codereview.chromium.**org/7736020/<http://codereview.chromium.org/7736020/> > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
