This is about quality of the GC and string implementation. A good one can detect that only a range of allocation is alive and release unused part of someLargeString. The GC could also flatten a deep nested tree of strings in implementations based on ropes.
A good one can detect that only a range of allocation is alive and release unused part of someLargeString.
Can you give an example of a (somewhat widely-used) library/runtime that does this?
I think this is harder than it initially seems. How does the GC know that if you have some type with a backing array and two pointers (or indices) that I don't want to move one of the pointers to some other valid position later?
I am not arguing that it is not possible, but this seems difficult in the general case, unless you can explicitly provide hints to the garbage collector.
There is nothing difficult with that as long as the GC knows everything about strings and their pointers so it can detect that a particular string is reachable only through single another string.
At some point this for considered for JS engine in Firefox, but that was before introduction of ropes, small strings that holds string chars inline and various other optimizations like recent switch from UTF16 to byte per char for strings with Latin1 characters. That and the fact that Firefox flattens all strings that name properties of objects, this optimization is unnecessary on the current web.
There is nothing difficult with that as long as the GC knows everything about strings and their pointers so it can detect that a particular string is reachable only through single another string.
Right, but that is a specific case where a built-in data type is optimized. It's not difficult, because the GC knows the semantics of a specific data type. But this does not work in the general case of slicing of library/used-defined data types.
