[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

Fun,

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."
Osho



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