La dernière version de Go, version 1.12, arrive six mois après Go 1.11. La plupart de ses modifications concernent l'implémentation de la chaîne d'outils, du moteur d'exécution et des bibliothèques.Modules
Lorsque GO111MODULE est défini sur on, la commande go prend désormais en charge les opérations prenant en charge le module en dehors d'un répertoire de module, à condition que ces opérations n'aient pas besoin de résoudre les chemins d'importation relatifs au répertoire actuel ni de modifier explicitement le fichier go.mod. Les commandes telles que go get, go list et go mod download se comportent comme si elles se trouvaient dans un module dont les exigences étaient initialement vides. Dans ce mode, go env GOMOD indique le périphérique nul du système (/ dev / null ou NUL).
Les commandes go qui téléchargent et extraient les modules peuvent désormais être appelées simultanément. Le cache de module (GOPATH / pkg / mod) doit résider dans un système de fichiers prenant en charge le verrouillage de fichier.
La directive go dans un fichier go.mod indique maintenant la version du langage utilisée par les fichiers de ce module. Elle sera définie sur la version actuelle (cf. 1.12) si aucune version existante n’est présente. Si la directive go d'un module spécifie une version plus récente que la chaîne d'outils utilisée, la commande go tentera de générer les packages indépendamment et notera l'incompatibilité uniquement si cette génération échoue.
Lorsqu'une importation ne peut pas être résolue à l'aide des modules actifs, la commande go va tenter d'utiliser les modules mentionnés dans les directives de remplacement du module principal avant de consulter le cache du module et les sources réseau habituelles. Si un remplacement correspondant est trouvé mais que la directive replace ne spécifie pas de version, la commande go utilise une pseudo-version dérivée de zero time.Time (telle que v0.0.0-00010101000000-000000000000).
Chaîne d'outils du compilateur
L'analyse des variables en direct du compilateur s'est améliorée. Cela peut signifier que les finaliseurs seront exécutés plus tôt dans cette version que dans les versions précédentes. Si cela pose un problème, envisagez l’ajout approprié d’un appel runtime.KeepAlive.
De plus en plus de fonctions sont désormais éligibles pour une extension inline par défaut, y compris les fonctions qui n’appellent que d’autres fonctions. Cette intégration supplémentaire rend également important l'utilisation de runtime.CallersFrames au lieu d'itérer directement le résultat de runtime.Callers. Rappelons qu'en informatique, l'extension inline, ou inlining, est une optimisation d'un compilateur qui remplace un appel de fonction par le code de cette fonction. Cette optimisation vise à réduire le temps d'exécution ainsi que la consommation mémoire. Toutefois, l'extension inline peut augmenter la taille du programme (par la répétition du code d'une fonction).
Certains langages (par exemple le C ou le C++) ont un mot clé inline attachable à la définition d'une fonction. Ce mot clé indique au compilateur qu'il devrait essayer d'étendre cette fonction. Le compilateur pourra ensuite utiliser plusieurs heuristiques pour décider quelle fonction doit être étendue inline.
| Code Go : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 | // Ancien code qui ne fonctionne plus correctement (il va manquer des inlined call frames) var pcs [10]uintptr n := runtime.Callers(1, pcs[:]) for _, pc := range pcs[:n] { f := runtime.FuncForPC(pc) if f != nil { fmt.Println(f.Name()) } } |
| Code Go : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 | // Nouveau code qui fonctionne correctement. var pcs [10]uintptr n := runtime.Callers(1, pcs[:]) frames := runtime.CallersFrames(pcs[:n]) for { frame, more := frames.Next() fmt.Println(frame.Function) if !more { break } } |
Les wrappers générés par le compilateur pour implémenter les expressions de méthode ne sont plus signalés par runtime.CallersFrames et runtime.Stack. Ils ne sont également pas imprimés dans les traces de pile de panique. Cette modification aligne la chaîne d’outils gc sur la chaîne d’outils gccgo, qui supprimait déjà ces wrappers des traces de pile. Les clients de ces API peuvent avoir besoin d'ajuster les images manquantes. Pour le code devant interagir entre les versions 1.11 et 1.12, vous pouvez remplacer l'expression de méthode x.M par la fonction literal func (...) {x.M (...)}.
Le compilateur accepte maintenant un indicateur -lang pour définir la version de langage Go à utiliser. Par exemple, -lang = go1.8 amène le compilateur à émettre une erreur si le programme utilise des alias de type, qui ont été ajoutés dans Go 1.9. Les modifications de langage effectuées avant Go 1.12 ne sont pas systématiquement appliquées.
La chaîne d’outils du compilateur utilise désormais différentes conventions pour appeler des fonctions Go et des fonctions d’assemblage. Cela devrait être invisible pour les utilisateurs, sauf pour les appels qui traversent simultanément Go et assembly et franchissent les limites d'un paquet.
De nombreuses améliorations ont été apportées aux informations de débogage DWARF générées par le compilateur, notamment à l’impression des arguments et aux informations d’emplacement des variables.
Que signifie "panique" ?
La manière idiomatique de gérer des conditions anormales dans un programme en Go consiste à utiliser des erreurs. Les erreurs sont suffisantes pour la plupart des conditions anormales apparues dans le programme.
Mais il existe des situations où le programme ne peut simplement pas continuer à s'exécuter après une situation anormale. Dans ce cas, nous utilisons la panique pour terminer le programme. Lorsqu'une fonction rencontre une panique, son exécution est arrêtée, toutes les fonctions différées sont exécutées, puis le contrôle revient à l'appelant. Ce processus se poursuit jusqu'à ce que toutes les fonctions de la goroutine actuelle soient retournées. Le programme imprime alors le message de panique, suivi de la trace de la pile, puis se termine.
La trace de pile fournit, dans la plupart des cas, suffisamment d’informations pour identifier l’endroit où se produit la panique (dans cet exemple). Elle montre la chaîne d'appels de fonction et le fichier source avec le numéro de ligne auquel la fonction a été appelée.
Runtime
Le moteur d’exécution Go libère maintenant la mémoire dans le système d’exploitation de manière plus agressive, en particulier en réponse à des allocations importantes qui ne peuvent pas réutiliser l’espace de tas existant.
Le minuteur et le code de délai du runtime de Go sont plus rapides et s'adaptent mieux à un nombre plus élevé de processeurs. Cela améliore notamment les performances de manipulation des délais de connexion réseau.
Sous Linux, le runtime utilise maintenant MADV_FREE pour libérer de la mémoire inutilisée. Ceci est plus efficace mais peut entraîner une augmentation du RSS signalé. Le noyau récupérera les données inutilisées lorsque cela sera nécessaire. Pour revenir au comportement de Go 1.11 (MADV_DONTNEED), définissez la variable d'environnement GODEBUG = madvdontneed = 1.
L'ajout de cpu.extension = off à la variable d'environnement GODEBUG désactive désormais l'utilisation des extensions de jeu d'instructions d'UC facultatives dans la bibliothèque standard et au moment de l'exécution. Ceci n'est pas encore supporté sous Windows.
Go 1.12 améliore la précision des profils de mémoire en corrigeant le sur-comptage d'allocations de tas importantes.
Les services de trace, runtime.Caller et...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.