Тип System.String - один из самых используемых при разработке. В этой статье я хотел бы поговорить о нюансах его реализации, начнем с базовой информации:
System.String - это ссылочный тип;
System.String - это неизменяемый тип. На самом деле, строку нельзя изменить (по крайней мере с помощью безопасного кода). Все методы вроде .Trim, .Insert и пр. не изменяют содержимое строки, на которую первоначально ссылались, а просто устанавливают ссылку на новую.
Теперь заглянем немного глубже. Опираясь на наши вводные, посмотрим, как это устроено в памяти. Начнем с того, что строки (как и массивы) не фиксированы в размерах. Однако, стоит помнить, что экземпляр любого типа не может занимать в памяти больше 2Gb в памяти, это ограничение распространяется как на x86, так и x64 системы. Обычно GC знает о том, сколько места в памяти занимает объект при его создании. Потому что он основан на определенных типах и свойствах, которые не меняются. Но это не наш случай. Давайте разберемся. Под катом строка не ссылается на массив char’ом, а содержит их внутри. Если обратиться к исходникам, то мы обнаружим эти два замечательных поля.
// The String class represents a static string of characters. Many of
// the string methods perform some type of transformation on the current
// instance and return the result as a new string. As with arrays, character
// positions (indices) are zero-based.
[Serializable]
[NonVersionable] // This only applies to field layout
[System.Runtime.CompilerServices.TypeForwardedFrom("mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089")]
public sealed partial class String{
// Остальной код
//
// These fields map directly onto the fields in an EE StringObject. See object.h for the layout.
//
[NonSerialize]
private readonly int _stringLength;
// For empty strings, _firstChar will be '\0', since strings are both null-terminated and length-prefixed.
// The field is also read-only, however String uses .ctors that C# doesn't recognise as .ctors,
// so trying to mark the field as 'readonly' causes the compiler to complain.
[NonSerialized]
private char _firstChar;
//Остальной код
}Класс String в C# - это управляемый исходный файл, но большая часть его кода реализована на C или ассемблере. В файле String.cs содержится 9 методов, которые помечены как extern и аннотированы атрибутом MethodImplAttribute с параметром InternalCall. Это говорит о том, что их реализации предоставляются исполняющей средой в другом месте.
Чтобы разобраться лучше перейдем в layout object.h и увидим:
/*
* StringObject
*
* Special String implementation for performance.
*
* m_StringLength - Length of string in number of WCHARs
* m_FirstChar - The string buffer
*
*/
class StringObject : public Object{
// Остальной код
private:
DWORD m_StringLength;
WCHAR m_FirstChar;
// Остальной код
}Получатся, вот так GC будет видеть строку в памяти:
Именно так, потому что следующие m_StringLength байт будут заняты массивом данных этой строки. В таком случае фактические строковые данные не будут храниться в массиве байтов, расположенном в другом месте памяти, и поэтому для их обнаружения не требуется ссылка на указатель и их поиск.
Давайте рассмотрим всю картину, сколько в итоге памяти занимает строка?
8 (sync) + 8 (type) + 4 (length) + 4(extra field) + 2 (null terminator) + 2 * length
Получается: 26 + 2 * length
8 байт - SyncBlock, 8 байт - Method table pointer, тут все понятно.
4 байт - m_stringLength member, фактическое количество символов в строке
4 байт - extra field, до .NET 4.0 это место было отведено для m_arrayLength. В предыдущих реализациях длинна строки могла отличаться от длинны массива символов, входящего в нее. В последующих версиях эта память была сохранена и оставлена пустой. Вероятнее для исключение проблем с кодом pinvoke.
2 * length - по два байта на каждый символ, начиная с m_FirstChar. Строки всегда имеют кодировку Unicode. Это очень важно знать и понимать. Работа с строкой так, будто она представлена в другой кодировке, практически всегда является ошибкой. Набор кодированных символов Unicode содержит более 65536 символов. Это означает, что один символ (System.Char) не может охватывать все символы. Это приводит к использованию суррогатов, где символы выше U+FFFF представлены в строках как два символа. По сути, строка использует форму кодировки символов UTF-16. Большинству разработчиков, возможно, не нужно много знать об этом, но, по крайней мере, знать об этом стоит.
2 байта - Null terminator. Хотя строки не заканчиваются Null (не путать с ключевым словом null) с точки зрения API, массив символов завершается Null, так как это означает, что он может быть передан непосредственно в неуправляемые функции без какого-либо копирования. При условии, что взаимодействие указывает, что символы в строке должны быть маршалированны как Unicode.
Основное различие между x86 и x64 системами заключается в размере DWORD – указателя памяти. В 32-битных системах он составляет 4 байта, в 64-битных уже 8 байт.
Но как GC выделяет память для объекта, размер которого он не знает? Ответ прост: никак. Обычно сначала GC выделяет память, а потом вызывается конструктор класса. С String все иначе, при инициализации типа сам конструктор выделяет память для объекта. Рассмотрим на примере.
Для работы с строками чаще всего используется String.Builder или String.Format (который в конечном итоге использует String.Builder). В конечном итоге, вызывается метод StringBuilder.ToString(), он же внутри вызывает FastAllocateString для класса String:
public override string ToString()
{
//Остальной код
string result = string.FastAllocateString(Length);
//Остальной код
}Рассмотрим его подробнее.
// This class is marked EagerStaticClassConstruction because it's nice to have this
// eagerly constructed to avoid the cost of defered ctors. I can't imagine any app that doesn't use string
[EagerStaticClassConstruction]
public partial class String
{
[Intrinsic]
public static readonly string Empty = "";
internal static string FastAllocateString(int length)
{
// We allocate one extra char as an interop convenience so that our strings are null-
// terminated, however, we don't pass the extra +1 to the string allocation because the base
// size of this object includes the _firstChar field.
string newStr = RuntimeImports.RhNewString(EETypePtr.EETypePtrOf<string>(), length);
Debug.Assert(newStr._stringLength == length);
return newStr;
}
}Оказывается, это просто обертка, найдем RhNewString:
[MethodImpl(MethodImplOptions.InternalCall)]
[RuntimeImport(RuntimeLibrary, "RhNewString")]
internal static extern unsafe string RhNewString(MethodTable* pEEType, int length);
internal static unsafe string RhNewString(EETypePtr pEEType, int length)
=> RhNewString(pEEType.ToPointer(), length);Этот метод помечен как внешний и к нему применен атрибут [MethodImpl(MethodImplOptions.InternalCall)], это означает, что он будет реализован CLR в неуправляемом коде. В конечном итоге стек вызовов оказывается в написанной от руки ассемблерной функции:
;; Allocate a new string.
;; ECX == MethodTable
;; EDX == element count
FASTCALL_FUNC RhNewString, 8
push ecx
push edx
;; Make sure computing the aligned overall allocation size won't overflow
cmp edx, MAX_STRING_LENGTH
ja StringSizeOverflow
; Compute overall allocation size (align(base size + (element size * elements), 4)).
lea eax, [(edx * STRING_COMPONENT_SIZE) + (STRING_BASE_SIZE + 3)]
and eax, -4
; ECX == MethodTable
; EAX == allocation size
; EDX == scratch
INLINE_GETTHREAD edx, ecx ; edx = GetThread(), TRASHES ecx
; ECX == scratch
; EAX == allocation size
; EDX == thread
mov ecx, eax
add eax, [edx + OFFSETOF__Thread__m_alloc_context__alloc_ptr]
jc StringAllocContextOverflow
cmp eax, [edx + OFFSETOF__Thread__m_alloc_context__alloc_limit]
ja StringAllocContextOverflow
; ECX == allocation size
; EAX == new alloc ptr
; EDX == thread
; set the new alloc pointer
mov [edx + OFFSETOF__Thread__m_alloc_context__alloc_ptr], eax
; calc the new object pointer
sub eax, ecx
pop edx
pop ecx
; set the new object's MethodTable pointer and element count
mov [eax + OFFSETOF__Object__m_pEEType], ecx
mov [eax + OFFSETOF__String__m_Length], edx
retЭто также показывает кое-что еще, о чем мы говорили ранее. Ассемблерный код фактически выделяет память, необходимую для строки, на основе требуемой длины, переданной вызывающим кодом.
С одной стороны, строки являются фундаментальным типом, именно поэтому должны быть максимально оптимизированы. С другой стороны, для такого базового типа строки (и текстовые данные в целом) имеют большую сложность, чем изначально можно предполагать. Информация, предложенная в статье, не является исчерпывающей, но поможет вам лучше понимать процессы, происходящие под катом ваших проектов.
