Примечания к выпуску Go 1.2

<code>type T struct {
  X [1<<24]byte
  Field int32
}

func main() {
  var x *T
  ...
}
</code>

<code>var array [10]int
slice := array[2:4]
</code>

<code>slice = array[2:4:7]
</code>

Изменения в реализации и инструментах

Предварительная отмена выполнения в планировщике

В предыдущих версиях, горутина, которая выполняла бесконечный цикл, могла вытеснить другие горутины, работающие в том же потоке, что представляло серьезную проблему, когда GOMAXPROCS задавало только один пользовательский поток.

В Go 1.2 это частично устранено: планировщик вызывается время от времени при входе в функцию. Это означает, что любой цикл, содержащий вызов (не встроенной) функции, может быть прерван, позволяя другим горутинам выполнятся в том же потоке.

Ограничение на количество потоков

Go 1.2 вводит настраиваемое ограничение (по умолчанию 10 000) на общее количество потоков, которое может быть в адресном пространстве одного программного обеспечения, чтобы избежать проблем с нехваткой ресурсов в некоторых средах. Обратите внимание, что горутины мультиплексируются на потоки, поэтому это ограничение не ограничивает напрямую количество горутин, а только количество, которое может одновременно блокироваться в системном вызове. На практике это ограничение трудно достичь.

Новая функция SetMaxThreads в пакете runtime/debug управляет лимитом количества потоков.

Обновление: Мало функций будут затронуты этим лимитом, но если программа завершается из-за достижения лимита, её можно изменить, чтобы вызвать SetMaxThreads для установки более высокого значения. Ещё лучше будет рефакторинг программы, чтобы она использовала меньше потоков, тем самым уменьшив потребление ресурсов ядра.

Размер стека

В Go 1.2 минимальный размер стека при создании горутины был увеличен с 4 КБ до 8 КБ. Многие программы страдали от проблем с производительностью при использовании старого размера, который часто приводил к дорогостоящему переключению сегментов стека в критических по производительности участках кода. Новое значение было определено эмпирическим путем.

С другой стороны, новая функция SetMaxStack в пакете runtime/debug управляет максимальным размером стека одной горутины. По умолчанию это 1 ГБ на 64-битных системах и 250 МБ на 32-битных системах. До Go 1.2 было слишком легко уйти в бесконечную рекурсию, которая потребляла всю память машины.

Обновление: Увеличенный минимальный размер стека может привести к тому, что программы с большим количеством горутин будут использовать больше памяти. Решения нет, но в будущих релизах планируется внедрение новых технологий управления стеком, которые должны лучше решить эту проблему.

Cgo и C++

Команда cgo теперь будет вызывать компилятор C++ для сборки частей связанной библиотеки, написанных на C++; документация содержит дополнительные сведения.

Godoc и vet перемещены в подрепозиторий go.tools

Оба бинарных файла по-прежнему включены в дистрибутив, но исходный код команд godoc и vet был перемещён в подрепозиторий go.tools.

Кроме того, ядро программы godoc было разделено на библиотеку, в то время как сама команда находится в отдельной директории. Перемещение позволяет легко обновлять код, а разбиение на библиотеку и команду упрощает создание пользовательских бинарных файлов для локальных сайтов и различных способов развертывания.

Обновление: Поскольку godoc и vet не являются частью библиотеки, никакой клиентский Go-код не зависит от их исходного кода, и обновление не требуется.

Двоичные дистрибутивы, доступные на golang.org, включают эти бинарные файлы, поэтому пользователи этих дистрибутивов не пострадают.

При сборке из исходников, пользователи должны использовать команду “go get” для установки godoc и vet. (Бинарные файлы будут продолжать устанавливаться в обычные места, а не $GOPATH/bin.)

<code>$ go get code.google.com/p/go.tools/cmd/godoc
$ go get code.google.com/p/go.tools/cmd/vet
</code>

Состояние gccgo

Ожидается, что будущий выпуск GCC 4.9 будет включать gccgo с полной поддержкой Go 1.2. В текущем (4.8.2) выпуске GCC, gccgo реализует Go 1.1.2.

Изменения в компиляторе gc и линковщике

Go 1.2 имеет несколько семантических изменений в работе компиляторной среды gc. Большинство пользователей не пострадают от этих изменений.

Команда cgo теперь работает, когда C++ включено в библиотеку, к которой происходит линковка. См. документацию cgo для получения дополнительных сведений.

Компилятор gc отображал устаревший деталь своего происхождения, когда программа не имела инструкции package: он предполагал, что файл находится в пакете main. Прошлое было стёрто, и отсутствие инструкции package теперь является ошибкой.

В ARM-среде, инструментарий поддерживает «внешнюю линковку», что является шагом к возможности сборки общих библиотек с использованием компилятора gc и предоставления поддержки динамической линковки в средах, где это необходимо.

В среде выполнения для ARM, с 5a, раньше было возможно напрямую ссылаться на внутренние переменные среды выполнения m (машина) и g (горутина), используя R9 и R10. Теперь необходимо ссылаться на них по их правильным именам.

Также в ARM, линковщик 5l (sic) теперь определяет инструкции MOVBS и MOVHS как синонимы MOVB и MOVH, чтобы сделать более очевидным разделение между знаковыми и беззнаковыми перемещениями подслов; беззнаковые версии уже существовали с суффиксом U.

Покрытие тестами

Одной из главных новых функций go test является способность вычислять и, с помощью новой отдельно установленной программы «go tool cover», отображать результаты покрытия тестами.

Инструмент cover входит в состав go.tools подрепозитория. Он может быть установлен с помощью команды

<code>$ go get code.google.com/p/go.tools/cmd/cover
</code>

Инструмент cover выполняет две функции. Во-первых, когда «go test» получает флаг -cover, он автоматически запускается, чтобы переписать исходный код пакета и вставить инструкции инструментирования. Затем тест компилируется и запускается как обычно, и выводятся базовые статистические данные о покрытии:

<code>$ go test -cover fmt
ok      fmt 0.060s  coverage: 91.4% of statements
$
</code>

Во-вторых, для более подробных отчетов, различные флаги команды «go test» могут создавать файл профиля покрытия, который программа cover, вызванная через «go tool cover», затем может анализировать.

Подробности о том, как генерировать и анализировать статистику покрытия, можно найти, выполнив команды

<code>$ go help testflag
$ go tool cover -help
</code>

Команда go doc удалена

Команда «go doc» удалена. Обратите внимание, что сам инструмент godoc не удаляется, только его обёртка через команду go. Всё, что она делала — это отображала документацию для пакета по пути пакета, что уже делает godoc сам по себе с большей гибкостью. Поэтому она была удалена с целью уменьшения количества инструментов документации и, в рамках реорганизации godoc, поощрения лучших вариантов в будущем.

Обновление: Для тех, кто всё ещё нуждается в точной функциональности запуска

<code>$ go doc
</code>

в каталоге, поведение будет идентичным запуску

<code>$ godoc .
</code>

Изменения в команде go

Команда go get теперь имеет флаг -t, который заставляет её скачивать зависимости тестов, запускаемых пакетом, а не только зависимости самого пакета. По умолчанию, как и раньше, зависимости тестов не скачиваются.

Производительность

В стандартной библиотеке были реализованы значительные улучшения производительности; вот некоторые из них.

• Пакет compress/bzip2 осуществляет декомпрессию примерно на 30% быстрее.
• Пакет crypto/des работает примерно в пять раз быстрее.
• Пакет encoding/json осуществляет кодирование примерно на 30% быстрее.
• Производительность сетевых операций в системах Windows и BSD увеличена примерно на 30% благодаря использованию интегрированного сетевого опросника в среде выполнения, аналогичного тому, что было реализовано для Linux и OS X в Go 1.1.

Изменения в стандартной библиотеке

Пакеты archive/tar и archive/zip

В пакетах archive/tar и archive/zip произошло изменение семантики, которое может привести к поломке существующих программ. Проблема заключается в том, что оба пакета предоставляли реализацию интерфейса os.FileInfo, не соответствующую спецификации этого интерфейса. В частности, их метод Name возвращал полный путь к записи, тогда как спецификация интерфейса требует, чтобы метод возвращал только базовое имя (последний элемент пути).

Обновление: Поскольку это поведение было недавно реализовано и немного скрыто, возможно, ни один код не зависит от сломанного поведения. Если существуют программы, которые зависят от него, их необходимо будет вручную идентифицировать и исправить.

Новый пакет encoding

Появился новый пакет encoding, определяющий набор стандартных интерфейсов кодирования, которые могут использоваться для создания пользовательских маршалеров и демаршалеров для таких пакетов, как encoding/xml, encoding/json, и encoding/binary. Эти новые интерфейсы были использованы для улучшения некоторых реализаций в стандартной библиотеке.

Новые интерфейсы называются BinaryMarshaler, BinaryUnmarshaler, TextMarshaler, и TextUnmarshaler. Подробности содержатся в документации пакета и в отдельном документе проектирования.

Пакет fmt

Форматированные функции печати пакета fmt, такие как Printf, теперь позволяют получать элементы данных для печати в произвольном порядке, используя операцию индексации в спецификациях форматирования. Где бы ни требовалось извлечь аргумент из списка аргументов для форматирования, либо как значение для форматирования, либо как целое число ширины или спецификации, новая необязательная нотация индексации [n] извлекает аргумент n вместо него. Значение n является 1-индексированным. После такой операции индексации следующий аргумент для обычной обработки будет n+1.

Например, обычный вызов Printf

<code>fmt.Sprintf("%c %c %c\n", 'a', 'b', 'c')
</code>

создаст строку "a b c", но с использованием операций индексации, как в этом примере,

<code>fmt.Sprintf("%[3]c %[1]c %c\n", 'a', 'b', 'c')
</code>

результат будет ""c a b". Индекс [3] обращается к третьему аргументу форматирования, который равен 'c', [1] обращается к первому, 'a', а затем следующая операция извлечения обращается к аргументу, следующему за ним, 'b'.

Мотивацией для этой функции является возможность программно формировать инструкции форматирования для доступа к аргументам в разном порядке, что полезно для локализации, но у нее есть и другие применения: