Die grössten Entwicklungen bei der Implementierung sind:
Diese und eine Reihe anderer Änderungen an der Implementierung und den Tools werden nachstehend erläutert.
Die Version enthält auch eine kleine Sprachänderung mit Map literals.
m := map[Point]string {
Point{29.935523, 52.891566}: "Persepolis",
Point{-25.352594, 131.034361}: "Uluru",
Point{37.422455, -122.084306}: "Googleplex",
}
kann wie folgt geschrieben werden, ohne den explizit aufgeführten Typ Point:
m := map[Point]string {
{29.935523, 52.891566}: "Persepolis",
{-25.352594, 131.034361}: "Uluru",
{37.422455, -122.084306}: "Googleplex",
}
Der Compiler und die Laufzeit sind jetzt in Go und Assembler ohne C implementiert. Die einzige im Tree verbleibende C-Quelle bezieht sich auf das Testen oder auf cgo. In Go 1.4 und früheren Versionen befand sich ein C-Compiler im Tree. Er wurde verwendet, um die Laufzeit zu erstellen; Zum Teil war ein benutzerdefinierter Compiler erforderlich, um sicherzustellen, dass der C-Code mit der Stapelverwaltung von Goroutinen funktioniert. Da die Laufzeit jetzt in Go ist, wird dieser C-Compiler nicht benötigt und ist weg.
Die Konvertierung von C wurde mit Hilfe von benutzerdefinierten Tools durchgeführt, die für den Job erstellt wurden. Am wichtigsten ist, dass der Compiler tatsächlich durch automatische Übersetzung des C-Codes in Go verschoben wurde. Es ist praktisch das gleiche Programm in einer anderen Sprache. Es handelt sich nicht um eine neue Implementierung des Compilers, daher erwarten wir, dass der Prozess keine neuen Compiler-Fehler verursacht hat.
Unabhängig von der Umstellung auf Go haben sich die Namen der Tools geändert. Die alten Namen 6g, 8g ... sind weg; Stattdessen gibt es nur eine Binärdatei, auf die zugegriffen werden go tool compile kann, um die Go-Quelle in Binärdateien zu kompilieren, die für die durch $GOARCH und $GOOS angegebene Architektur und Betriebssystem geeignet sind. Ebenso gibt es jetzt einen Linker (go tool link) und einen Assembler (go tool asm). Der Linker wurde automatisch aus der alten C-Implementierung übersetzt, aber der Assembler ist eine neue native Go-Implementierung, die weiter unten ausführlicher beschrieben wird.
Ähnlich wie die Entfernung der Namen 6g, 8g ..., ist die Ausgabe des Compilers und Assembler nun alle mit dem .o Suffix statt .8, .6 etc. gegeben.
Der Garbage Collector wurde für die Version 1.5 als Teil der Entwicklung des skizzierte Re-engineered Designdokument. Erwartete Latenzen sind viel niedriger als mit dem Collector in früheren Versionen durch eine Kombination von fortschrittlichen Algorithmen, besserem Scheduling und durch die parallele Ausführung. Die "Stop the World" -Phase des Collectors liegt fast immer unter 10 Millisekunden oder deutlich darunter.
Bei Systemen, die von einer geringen Latenz profitieren, z. B. Websites, die auf Benutzer reagieren, kann der Rückgang der erwarteten Latenz mit dem neuen Collector wichtig sein.
In Go 1.5 wurde die Reihenfolge geändert, in der Goroutinen ausgeführt werden. Die Eigenschaften des Schedulers wurden nie durch die Sprache selbst definiert, aber Programme, die von der geplanten Ausführungsreihenfolge abhängen, können durch diese Änderung beeinträchtigt werden. Wir haben einige (fehlerhafte) Programme gesehen, die von dieser Änderung betroffen sind. Wenn Sie Programme haben, die implizit von der Ausführungsreihenfolge abhängen, müssen Sie diese anpassen.
Eine weitere wichtige Änderung besteht darin, dass die Laufzeit jetzt die Standardanzahl der gleichzeitig ausgeführten Threads GOMAXPROCS auf die Anzahl der auf der CPU verfügbaren Kerne festlegt. In früheren Versionen war der Standardwert 1. Programme, die nicht mit mehreren CPU Kernen ausgeführt werden sollen, können versehentlich unterbrochen werden. Sie können die Einschränkung aufgeheben oder GOMAXPROCS explizit festgelegen.
Nachdem der Go-Compiler und die Runtime in Go implementiert sind, muss ein Go-Compiler verfügbar sein, um die Distribution aus dem Quellcode zu kompilieren. Um den Go-Kern aufzubauen, muss daher bereits eine funktionierende Go-Distribution vorhanden sein. (Go-Programmierer, die nicht am Core arbeiten, sind von dieser Änderung nicht betroffen.) Jede Go 1.4- oder spätere Distribution (einschliesslich gccgo) wird bereitgestellt.
Es stehen jedoch mehrere neue Ports zur Verfügung, die aus dem Quellcode erstellt werden können. Dazu gehören darwin/armund und darwin/arm64. Der neue Port linux/arm64 ist grösstenteils vorhanden, wird jedoch cgo nur über external Linking unterstützten.
Ebenfalls als Experimente erhältlich sind ppc64 und ppc64le (64-Bit-PowerPC, Big- und Little-Endian). Beide Ports unterstützen cgo jedoch nur mit internal Linking.
Unter FreeBSD benötigt Go 1.5 FreeBSD 8-STABLE+, da die SYSCALL Anweisung neu verwendet wird.
Für NaCl benötigt Go 1.5 die SDK-Version Pepper-41. Spätere Pfefferversionen sind nicht kompatibel, da das sRPC-Subsystem aus der NaCl-Laufzeit entfernt wurde.
Unter Darwin kann die Verwendung der System X.509-Zertifikatschnittstelle mit dem ios Build-Tag deaktiviert werden .
Der Solaris-Port hat jetzt volle Unterstützung für CGO und die Pakete net und crypto/x509 sowie eine Reihe weiterer Korrekturen und Verbesserungen.
Der Assembler ist jedoch ein neues Programm; es wird unten beschrieben.
Die Compiler (6g, 8g usw.), die Assembler (6a, 8a usw.), und die Linker (6l, 8l usw.) wurden im gleichen Werkzeug kombiniert, die durch die Umgebungsvariablen konfiguriert ist, GOOS und GOARCH. Die alten Namen sind weg; die neuen Werkzeuge sind durch die verfügbaren go tool Funktionen wie go tool compile, go tool asm und go tool link. Die Dateiendungen .6, .8 usw. wurden entfernt; Jetzt sind es nur noch einfache .o Dateien.
Wenn Sie beispielsweise ein Programm auf amd64 für Darwin erstellen und linken möchten ohne go build sondern durch die direkte Anwendung der Tools so führen Sie das folgende Script aus:
$ export GOOS=darwin GOARCH=amd64
$ go tool compile program.go
$ go tool link program.o
Der 1.5-Compiler entspricht grösstenteils dem alten, aber einige interne Details haben sich geändert. Eine wesentliche Änderung besteht darin, dass bei der Auswertung von Konstanten jetzt das math/big Paket anstelle einer benutzerdefinierten (und weniger gut getesteten) Implementierung hochpräziser Arithmetik verwendet wird. Wir erwarten nicht, dass dies die Ergebnisse beeinflusst.
Nur für die amd64-Architektur verfügt der Compiler über eine neue Option -dynlink, welche die dynamische Verknüpfung unterstützt, indem Verweise auf Go-Symbole unterstützt werden, die in externen gemeinsam genutzten Bibliotheken definiert sind.
Der neue Assembler ist nahezu kompatibel mit den vorherigen, es gibt jedoch einige Änderungen, die sich auf einige Assembler-Quelldateien auswirken können. Weitere Informationen zu diesen Änderungen finden Sie im aktualisierten Assembler-Handbuch. Zusammenfassend:
constant=value
um eine benannte Konstante zu definieren. Da dies immer mit der traditionellen C-ähnlichen #define Notation möglich ist, die weiterhin unterstützt wird (der Assembler enthält eine Implementierung eines vereinfachten C-Präprozessors), wurde die Funktion entfernt.Es gibt mehrere andere Änderungen. Das wichtigste ist das Hinzufügen einer -buildmode Option, die den Verknüpfungsstil erweitert. Es unterstützt jetzt Situationen wie das Erstellen gemeinsam genutzter Bibliotheken und das Aufrufen anderer Sprachen in Go-Bibliotheken. Einige davon wurden in einem Designdokument beschrieben . Eine Liste der verfügbaren Build Modes finden Sie via
$ go help buildmode
Eine weitere kleine Änderung besteht darin, dass der Linker keine Build-Zeitstempel mehr im Header der ausführbaren Windows-Dateien aufzeichnet. Obwohl dies möglicherweise behoben ist, fehlen in den ausführbaren Dateien von Windows cgo einige DWARF-Informationen.
Schließlich das -X Flag, das zwei Argumente akzeptiert, wie in
-X Wert für importpath.name
Akzeptiert jetzt auch einen allgemeineren Go-Flag-Stil mit einem einzelnen Argument, das selbst ein name=valuePaar ist:
-X importpath.name = value
Obwohl die alte Syntax weiterhin funktioniert, wird empfohlen, die Verwendung dieses Flags in Skripten und dergleichen auf das neue Format anzupassen.
In der vorherigen Version wurde die Idee eingeführt, dass ein internes Verzeichnis eines Pakets über den go Befehl nicht importierbar ist. In 1.4 wurde es mit der Einführung einiger interner Elemente im Kern-Repository getestet. Wie im Entwurfsdokument vorgeschlagen, wird diese Änderung nun allen Repositorys zur Verfügung gestellt. Die Regeln werden im Entwurfsdokument erläutert. Zusammenfassend kann jedoch jedes Paket in oder unter einem Verzeichnis mit dem Namen internalvon Paketen importiert werden, die im selben Teilbaum verwurzelt sind. Bestehende Pakete mit den genannten Verzeichniselementen können intern durch diese Änderung versehentlich beschädigt werden, weshalb sie in der letzten Version angekündigt wurden.
Eine weitere Änderung im Umgang mit Paketen ist die experimentelle Hinzufügung der Unterstützung für "Vendoring".
Es gab auch einige weitere kleine Änderungen:
$ go test -trace = trace.out Pfad / zu / Paket
$ go tool trace [flags] pkg.test trace.out
Mit den Flags kann die Ausgabe in einem Browserfenster angezeigt werden. Für Details führen Sie go tool trace -help aus. Builds in Go 1.5 sind um den Faktor zwei langsamer. Die automatische Übersetzung des Compilers und Linkers von C nach Go führte zu einem unidiomatischen Go-Code, der im Vergleich zu gut geschriebenem Go eine schlechte Leistung erbringt. Analysetools und Refactoring haben zur Verbesserung des Codes beigetragen, aber es bleibt noch viel zu tun. Weitere Optimierungen werden in Go 1.6 und zukünftigen Versionen fortgesetzt.
cpuFlag = flag.Int("cpu", 1, "run `N` processes in parallel")
zeigt die Message:-cpu N. run N processes in parallel (default 1)
Ausserdem wird der Standard jetzt nur aufgelistet, wenn es sich nicht um einen Nullwert handelt.
Im Zusammenhang mit dieser Verschiebung wurde das go/constant Package vom golang.org/x/tools/exact Package in das Hauptrepository verschoben. Das go/importer Package wurde auch in das Haupt-Repository sowie in einige der oben beschriebenen Tools verschoben.
Die Entscheidung, wie der Resolver ausgeführt werden soll, gilt zur Laufzeit und nicht zur Erstellungszeit. Das netgo Build-Tag, mit dem die Verwendung des Go-Resolvers erzwungen wurde, ist nicht mehr erforderlich, obwohl es weiterhin funktioniert. Ein neues netcgo Build-Tag erzwingt die Verwendung des cgo Resolvers zur Build-Zeit. Die Forcierung der cgo Auflösung kann mit der Umgebungsvariablen GODEBUG=netdns=cgo in der Umgebung festgelegten werden.
Diese Änderung gilt nur für Unix-Systeme. Windows-, Mac OS X- und Plan 9-Systeme verhalten sich wie zuvor.