[Mono-dev] Getting rid of String.InternalSetLength

Rafael Teixeira monoman at gmail.com
Fri Dec 4 10:29:01 EST 2009

One such alternative is to be more similar to ArrayLists that have
both a Capacity and a Length attributes, but that is surely overkill
as Strings are immutable after creation, so I think StringBuilder is
the one messing with the immutability of strings and should be
corrected as you propose


Rafael "Monoman" Teixeira
"To be creative means to be in love with life. You can be creative
only if you love life enough that you want to enhance its beauty, you
want to bring a little more music to it, a little more poetry to it, a
little more dance to it."

On Thu, Dec 3, 2009 at 4:02 PM, Mark Probst <mark.probst at gmail.com> wrote:
> SGen, our new garbage collector, doesn't explicitly store an object's
> size but determines it via the object's vtable and, in the case of
> arrays and strings, via the length field.  String.InternalSetLength
> changes that length field, which means that, from SGen's view, the
> string's size changes.  That's a problem because depending on an
> object's size it is either stored in a regular heap section or, if it
> is larger than a certain threshold, in the large object section (LOS).
>  SGen depends on being able to distinguish between the two, so it must
> not happen that an object changes size, i.e. we have to get rid of
> String.InternalSetLength, which is used by StringBuilder.
> The attached patch fixes this problem, but of course it has to do more
> copying.  Does anybody object to this?  Any alternatives?
> Mark
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

More information about the Mono-devel-list mailing list