There is a third alternative I just thought of: instead of changing the shape from sliced string into a seq string during promotion, we could keep the shape of the sliced string, but have it point to a newly created parent string which contains only the content relevant to the substring and reset the offset of the slice to 0, similar to a flat cons. This would not solve the problem with space explosion though.
- Yang On Tue, Aug 30, 2011 at 5:42 PM, Yang Guo <[email protected]> wrote: > 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
