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

Изменения в сборщике мусора

Некоторое время назад сборщик мусора стал точным при анализе значений в куче; в релизе Go 1.3 добавлена эквивалентная точность для значений на стеке. Это означает, что непоказательное значение Go, например целое число, никогда не будет ошибочно воспринято как указатель и не помешает освобождению неиспользуемой памяти.

Начиная с Go 1.3, среда выполнения предполагает, что значения с типом указателя содержат указатели, а другие значения — нет. Это предположение лежит в основе точного поведения как расширения стека, так и сборки мусора. Программы, использующие пакет unsafe для хранения целых чисел в значениях с типом указателя, являются недопустимыми и будут аварийно завершаться, если среда выполнения обнаружит такое поведение. Программы, использующие пакет unsafe для хранения указателей в значениях с целочисленным типом, также являются недопустимыми, но более трудно диагностируются во время выполнения. Поскольку указатели скрыты от среды выполнения, расширение стека или сборка мусора могут освободить память, на которую они указывают, создавая висячие указатели.

Обновление: Код, который использует unsafe.Pointer для преобразования целочисленного значения, хранящегося в памяти, в указатель, является недопустимым и должен быть переписан. Такой код может быть выявлен с помощью go vet.

Итерация по картам

Итерации по небольшим картам больше не происходят в определенном порядке. Go 1 определяет, что «Порядок итерации по картам не определён и не гарантируется одинаковым от одной итерации к другой.» Чтобы предотвратить зависимость кода от порядка итерации по картам, Go 1.0 начал каждую итерацию карты с случайного индекса в карте. Новая реализация карт, представленная в Go 1.1, забыла случайным образом изменять порядок итерации для карт с восемью или менее элементами, хотя порядок итерации может по-прежнему отличаться от системы к системе. Это позволило людям писать программы на Go 1.1 и Go 1.2, которые зависят от порядка итерации по небольшим картам, и поэтому работают надежно только на определённых системах. Go 1.3 снова вводит случайный порядок итерации для небольших карт, чтобы выявить эти ошибки.

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

Линкер

В рамках обобщённой рефакторинг линкера Go, компиляторы и линкеры были переработаны. Линкер по-прежнему является C-программой, но теперь фаза выбора инструкций, которая была частью линкера, была перемещена в компилятор через создание новой библиотеки под названием liblink. Выполняя выбор инструкций только один раз при первом компилировании пакета, это может значительно ускорить компиляцию больших проектов.

Обновление: Хотя это существенное внутреннее изменение, оно не должно влиять на программы.

Статус gccgo

Релиз GCC 4.9 будет содержать версию gccgo Go 1.2 (не 1.3). Графики релизов проектов GCC и Go не совпадают, что означает, что 1.3 будет доступна в ветке разработки, но следующий релиз GCC, 4.10, скорее всего будет содержать версию gccgo Go 1.4.

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

Команда cmd/go имеет несколько новых возможностей. Подкоманды go run и go test поддерживают новый параметр -exec для указания альтернативного способа запуска результирующего двоичного файла. Её прямое назначение — поддержка NaCl.

Поддержка покрытия тестов подкоманды go test теперь автоматически устанавливает режим покрытия в -atomic, когда включён детектор гонок, чтобы исключить ложные отчёты о нестандартном доступе к счётчикам покрытия.

Подкоманда go test теперь всегда собирает пакет, даже если в нём отсутствуют тестовые файлы. Ранее, если тестовые файлы отсутствовали, подкоманда ничего не делала.

Подкоманда go build поддерживает новый флаг -i, который позволяет установить зависимости указанной цели, но не саму цель.

Перекрёстная компиляция с включённым cgo теперь поддерживается. Переменные окружения CC_FOR_TARGET и CXX_FOR_TARGET используются при запуске all.bash для указания перекрёстных компиляторов для C и C++ кода соответственно.

Наконец, команда go теперь поддерживает пакеты, импортирующие Objective-C файлы (с расширением .m) через cgo.

Изменения в cgo

Команда cmd/cgo, которая обрабатывает объявления import "C" в пакетах Go, исправила серьёзную ошибку, которая могла привести к остановке компиляции некоторых пакетов. Ранее, все указатели на неполные структуры в Go переводились в тип *[0]byte, что мешало компилятору Go диагностировать передачу одного вида указателя на структуру в функцию, ожидающую другой. Go 1.3 исправляет эту ошибку, переводя каждую различную неполную структуру в отдельный именованный тип.

Для C-объявления typedef struct S T для неполной структуры struct S, некоторый Go-код использовал эту ошибку для неявного использования типов C.struct_S и C.T взаимозаменяемо. Теперь cgo явно разрешает такое использование, даже для завершённых структур. Однако, некоторые Go-программы также использовали эту ошибку для передачи (например) *C.FILE из одного пакета в другой. Это теперь недопустимо и больше не работает: в общем случае пакеты Go должны избегать экспозиции C-типов и имён в своих API.

Обновление: Код, который путает указатели на неполные типы или передаёт их через границы пакетов, больше не будет компилироваться и должен быть переписан. Если конверсия корректна и должна быть сохранена, используйте явное преобразование через unsafe.Pointer.

SWIG 3.0 требуется для программ, использующих SWIG

Для Go-программ, использующих SWIG, теперь требуется SWIG версии 3.0. Команда cmd/go теперь напрямую связывает сгенерированные SWIG файлы объектов в исполняемый файл, вместо того чтобы собирать и связывать с общими библиотеками.

Разбор флагов командной строки

В инструментарии gc, ассемблеры теперь используют те же правила разбора флагов командной строки, что и пакет flag в Go, что отличается от традиционного Unix-стиля разбора флагов. Это может повлиять на скрипты, которые вызывают инструмент напрямую. Например, go tool 6a -SDfoo теперь нужно писать как go tool 6a -S -D foo. (То же изменение было внесено в компиляторы и линковщики в Go 1.1.)

Изменения в godoc

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

Разное

Программа misc/benchcmp, которая сравнивает производительность между запусками бенчмарков, была переписана. Ранее она была обёрткой на shell и awk в основном репозитории, теперь она — Go-программа в репозитории go.tools. Документация доступна здесь.

Для тех немногих, кто собирает дистрибутивы Go, инструмент misc/dist был перемещён и переименован; он теперь находится в misc/makerelease, всё ещё в основном репозитории.

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

Производительность исполняемых файлов Go в данном релизе улучшена во многих случаях благодаря изменениям в среде выполнения и сборке мусора, а также некоторым изменениям в библиотеках. Значительные улучшения включают:

• Среда выполнения теперь обрабатывает defer более эффективно, снижая объем используемой памяти примерно на две килобайта на горутину, вызывающую defer.
• Сборщик мусора ускорен, используя конкурентный алгоритм очистки, лучшую параллелизацию и большие страницы. Кумулятивный эффект может составлять снижение времени пауз сборщика на 50–70%.
• Детектор гонок (см. это руководство) теперь работает примерно на 40% быстрее.
• Пакет регулярных выражений regexp теперь значительно быстрее для определённых простых выражений благодаря реализации второго одно-проходного движка выполнения. Выбор движка происходит автоматически; подробности скрыты от пользователя.

Кроме того, среда выполнения теперь включает в дампы стеков информацию о том, как долго горутина была заблокирована, что может быть полезно при отладке взаимоблокировок или проблем с производительностью.

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

Новые пакеты

В стандартную библиотеку был добавлен новый пакет debug/plan9obj. Он реализует доступ к объектным файлам Plan 9 a.out.

Значительные изменения в библиотеке

Ранее в crypto/tls существовала ошибка, которая позволяла случайно пропустить проверку TLS. В Go 1.3 эта ошибка исправлена: необходимо указать либо ServerName, либо InsecureSkipVerify, и если указан ServerName, он применяется строго. Это может привести к поломке существующего кода, который неправильно полагался на предыдущее поведение.

В net/http пакете теперь реализован новый метод Request.ParseMultipartForm, который теперь возвращает ошибку, если заголовок Content-Type тела запроса не является multipart/form-data. До Go 1.3 он молчаливо завершался и возвращал nil. Код, зависящий от предыдущего поведения, должен быть обновлён.