Golang Internals (часть 2): погружение в компилятор Go

Следующий логический шаг — найти runtime.typ2Itab . Ниже приведен список этой функции:

func typ2Itab(t *_type, inter *interfacetype, cache **itab) *itab {
	tab := getitab(inter, t, false)
	atomicstorep(unsafe.Pointer(cache), unsafe.Pointer(tab))
	return tab
}

Совершенно очевидно, что фактическая работа выполняется внутри метода getitab , потому что вторая строка просто хранит созданную переменную табуляции в кэше. Итак, давайте посмотрим внутрь getitab . Поскольку он довольно большой, я скопировал только самую ценную часть.

m = 
    (*itab)(persistentalloc(unsafe.Sizeof(itab{})+uintptr(len(inter.mhdr)-1)*ptrSize, 0,
    &memstats.other_sys))
    m.inter = interm._type = typ

ni := len(inter.mhdr)
nt := len(x.mhdr)
j := 0
for k := 0; k < ni; k++ {
	i := &inter.mhdr[k]
	iname := i.name
	ipkgpath := i.pkgpath
	itype := i._type
	for ; j < nt; j++ {
		t := &x.mhdr[j]
		if t.mtyp == itype && t.name == iname && t.pkgpath == ipkgpath {
			if m != nil {
				*(*unsafe.Pointer)(add(unsafe.Pointer(&m.fun[0]), uintptr(k)*ptrSize)) = t.ifn
			}
		}
	}
}

Сначала мы выделяем память для результата:

(*itab)(persistentalloc(unsafe.Sizeof(itab{})+uintptr(len(inter.mhdr)-1)*ptrSize, 0, &memstats.other_sys))

Почему мы должны выделять память в Go и почему это делается таким странным образом? Чтобы ответить на этот вопрос, нам нужно взглянуть на определение структуры itab .

type itab struct {
	inter  *interfacetype
	_type  *_type
	link   *itab
	bad    int32
	unused int32
	fun    [1]uintptr // variable sized
}

Последнее свойство, fun , определяется как массив из одного элемента, но на самом деле оно имеет переменный размер. Позже мы увидим, что это свойство содержит массив указателей на методы, определенные в определенном типе. Эти методы соответствуют методам в типе интерфейса. Авторы Go используют динамическое выделение памяти для этого свойства (да, такие вещи возможны, когда вы используете небезопасный пакет). Объем выделяемой памяти рассчитывается путем добавления размера самой структуры к числу методов в интерфейсе, умноженному на размер указателя.

unsafe.Sizeof(itab{})+uintptr(len(inter.mhdr)-1)*ptrSize

Далее вы можете увидеть два вложенных цикла. Сначала мы перебираем все методы интерфейса. Для каждого метода в интерфейсе мы пытаемся найти соответствующий метод в определенном типе (методы хранятся в коллекции mhdr ). Процесс проверки того, равны ли два метода, совершенно очевиден.

if t.mtyp == itype && t.name == iname && t.pkgpath == ipkgpath

Если мы находим совпадение, мы сохраняем указатель на метод в свойстве fun результата:

*(*unsafe.Pointer)(add(unsafe.Pointer(&m.fun[0]), uintptr(k)*ptrSize)) = t.ifn

Небольшое замечание о производительности: поскольку методы сортируются в алфавитном порядке для интерфейса и заданных определений типов, этот вложенный цикл может повторяться O (n + m) раз вместо O (n * m) раз, где n и m соответствуют числу методов. Наконец, вы помните последнюю часть задания?

AS l(16) 
.   NAME-main.i l(16) main.I
.   EFACE l(16) main.I
.   .   NAME-main.autotmp_0003 l(16) PTR64-*uint8
.   .   NAME-main.autotmp_0000 l(16) PTR64-*main.T

Здесь мы относим EFACE узел к переменной main.i. Этот узел ( EFACE ) содержит ссылки на переменную main.autotmp_0003 — указатель на структуру itab, возвращенную методом runtime.typ2Itab, — и на переменную autotmp_0000 , содержащую то же значение, что и переменная main.t. Это все, что нам нужно для вызова методов по интерфейсным ссылкам. Итак, переменная main.i содержит экземпляр структуры iface, определенной в пакете времени выполнения:

type iface struct {
	tab  *itab
	data unsafe.Pointer
}

Что дальше?

Я понимаю, что пока что рассмотрел только очень небольшую часть компилятора Go и среды выполнения Go. Есть еще много интересных вещей для обсуждения, таких как объектные файлы, компоновщик, перемещения и т. Д. — они будут рассмотрены в следующих публикациях в блоге.

Читать все части серии: Часть 1 | Часть 2 |  Часть 3 

Об авторе: Сергей Матюкевич — облачный инженер и разработчик Go в Altoros . С более чем 6-летним опытом в разработке программного обеспечения, он является экспертом в области облачной автоматизации и проектирования архитектур для сложных облачных систем. Активный участник сообщества Go, Сергей часто участвует в проектах с открытым исходным кодом, таких как Ubuntu и Juju Charms.